[kmf-discuss] Certificate management

[William Young]

Wyllys Ingersoll wrote:
> 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.
So if the certificate is self signed it is not anchored.  Why would it 
pass a validity check that requires an anchor?
> 
>>
>>    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?

	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.

	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?

>>>>
>>>>     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?
	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.
> 
>>
>> 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 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.
>  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}
encrypt|decrypt	{RSA], {[1|3]DES,AES}
hmac 		{MD5,SHA[1,2],RipeMD}

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