[kmf-discuss] Certificate management

[Wyllys Ingersoll]

Will Young wrote:
>>
>> If you have a self-signed cert, you cannot verify it with a TA.   A 
>> self-signed cert is it's own
>> TA.
>    I think I understand this, but from this I infer that if the 
> certificate is self signed and the subject does not match the 
> trust-anchor's dn for the policy then the certificate does not 
> validate under the policy.  In other words only a TA's certificate is 
> both self-signed and valid in a TA backed policy.
> i.e:
> subjectDN: A
> issuerDN: B
> trust-anchorDN: C
> self_signed means A == B
> t-a backed means B == C
>    so self_signed with a t-a back means A==C

I've never heard of "TA-Backed self-signed certs".  Either a cert is 
self-signed, or it is signed by a TA.

>
>    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).



>>>
>>>     I think we can do the essentials if we could use 
>>> ignore-trust-anchor=false together with a new 
>>> validate-trust-anchor=true and no longer be required to specify the 
>>> specific trust anchor.  KMF would then need to find the TA from the 
>>> issuerdn of the cert and make sure open O_VERIFY worked on the 
>>> issuer's cert file (assuming openssl) and 
>>> verify_cert_with_cert(cert, issuercert) was valid.
>>>
>>>     Signed exec could then work out the ability to further restrict 
>>> allowed manifest signers out of the world of valid signers in an 
>>> independent way.
>>>   
>>
>> Sounds like it could work.
> Cool.  I think I'll need to implement this in our project gate and get 
> your feedback.    My thinking based on your comments is that it will 
> need:
>
> kmf_initialize_attributes()
> with a new KMF attribute that ends up requiring O_VERIFY of the policy 
> (requires a new libxml2::xmlParserOption?) and gets added to the 
> handle->policy

In general, we just need new options or attributes support to 
"kmf_initialize()" and kmf_set_policy(), I dont think we need an 
entirely new function.


>
> Changes to the FindCert of openssl to attempt open O_VERIFY and 
> addition of
> a new flag in kmf_x509_private data for certificates that are O_VERIFY.

You want a private flag to indicate whether or not the cert was opened 
with O_VERIFY?

>
> A change to the policy xml for a trust-anchor-file-verify bool.  If 
> set the TA that comes back gets rejected if it lacks the new flag.
ok

>
>    The other issue that I still need a resolution for is how to solve 
> the situation where we have found a key via KMF and want to use it for 
> signing or encryption operations.  I don't think I should try to pull 
> out a raw key so we can default to one of the underlying encryption 
> libraries but the kmf operations are not as complete in having partial 
> update signing/encrypting/verifying or having as many algorithm 
> choices as the underlying encryption libraries.
>
>    The only clean way I know to handle this is still new plugin 
> operations for partial operations and separated algorithm attributes 
> for the key, digest, etc.

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 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.

-Wyllys