[kmf-discuss] Certificate management

[Will Young]

Wyllys Ingersoll wrote:
> Will Young wrote:
>> Wyllys Ingersoll wrote:
>>  
>>> Will Young wrote:  
>> Yes, so what is unclear to me is:
>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libkmf/libkmf/common/certop.c#2447 
>>
>> 2447    if (self_signed) {
>> 2448         ret = verify_cert_with_cert(handle, pcert, pcert);
>> 2449     } else {
>> 2450         ret = find_ta_cert(handle, kstype, &ta_cert,
>> ...
>>
>> if we are self_signed and a TA is specified, do we effectively know that
>> pcert matches what would result from find_ta_cert()?
>>   
>
> 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

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

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.

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.


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