[kmf-discuss] Certificate management

[Wyllys Ingersoll]

William Young wrote:
>
>>
>> I've never heard of "TA-Backed self-signed certs".  Either a cert is 
>> self-signed, or it is signed by a TA.
> So if the certificate is self signed it is not anchored.  Why would it 
> pass a validity check that requires an anchor?

Correct, they are not anchored.  Or, they are anchored to themselves.

The root TA of a PKI is always a self-signed cert that is extremely well 
secured and protected.


>>>
>>>    The code seems to say iff A != B then B == C which means anyone 
>>> who wants a TA backed policy must somehow discard unrelated 
>>> self-signed certificates that don't match the TA themselves.
>>
>> TA is meaningless for a self-signed cert.  The purpose of a TA is to 
>> provide a verifyable chain of authority, so that anyone participating 
>> in that particular PKI environment can know that they are dealing 
>> with an "authorized" member of the same PKI (in the simple case).
>     And someone with a self signed cert (with the rare exception of 
> the anchor itself) by definition lacks this chain back to the anchor, 
> so why are they valid?


They are generally only used in controlled environments or for testing 
purposes.  One does not normally have a PKI configured with lots of 
self-signed certificates being passed around, there is no security in 
that particular model.


>     I understand the possibility that you view a self signed 
> certificate as an exception.  I don't understand how this exception 
> can be in the certificates favor when passing a validity test.

When KMF verifies a self-signed cert, all it can do is verify that the 
self-signed cert was indeed signed by the private key associated with it.

>
>     I.e. if I were to create an IPsec policy to require Sun's CA as 
> the trust anchor, why do I want the self signed cert of "CN=John Q. 
> Malicious" to be valid under that policy?  Is it somehow better than a 
> certificate signed by an arbitrary CA I don't know?

You don't want it to be valid and it should not be if the PKI requires a 
TA check.  kmf_validate_cert() should probably require a new option (or 
have a new policy parameter) to allow or disallow self-signed certs.   
Currently it is defaulting to allowing self-signed certs to be used 
whether or not a TA is present, this is a probably a bug, it should 
default to NOT allowing them in that case.


[...]

>>
>> You want a private flag to indicate whether or not the cert was 
>> opened with O_VERIFY?
>     Yes, since we only care that we can verify the anchor we either 
> need to take a hint from the policy being verified that we should try 
> to open certificates verified and be able to fail the O_VERIFY and 
> still open it unverified or we need to explicitly pass the need to 
> open some certificates verified and some not.
>
>     I suspect there are edge case problems with using either strategy 
> alone, but I would rather start with the hint+flag since it is less 
> argument passing and will gracefully fail with the other plugins.

OK.


>>
>> Hmm, this is a slippery slope.  We do not want to duplicate the 
>> crypto framework functionality by adding a new set of
>> encrypt/digest/sign operations.   We will provide functions for doing 
>> those operations with a certificate (as opposed to a raw key) and we do
>> provide some sign/verify functionality.
>     If I could do a kmf_find_key() by a public key value I think I 
> could punt to the xmlsec-openssl module (or create a pkcs one) when 
> the keystore is not relevant.

Do you want to find the private key associated with a certificate?


>>  If you need additional algorithm support for those functions we 
>> already have, you could provide us with a list of the algorithms you 
>> want us to support and I can see if they will work within the 
>> boundaries of the KMF.
>     The current modules usually support:
> sign|verify    {RSA,DSA}, {MD5,SHA[1,2],RipeMD}
We have RSA/DSA MD5 and SHA[12], but do not have RipeMD. 
> encrypt|decrypt    {RSA], {[1|3]DES,AES}

We have those

> hmac         {MD5,SHA[1,2],RipeMD}
>

KMF doesn't offer any HMAC functions. 


>     I think I need the permutations of sign/verify from kmf (perhaps 
> due to signing only restricted keys?) and can decompose the encryption 
> related ones into asymmetric key operations with kmf and symetric/hmac 
> operations in pkcs11 or openssl.


ok.

-Wyllys