[kmf-discuss] Certificate management

[Wyllys Ingersoll]

Will Young wrote:
> Scott Rotondo wrote:
>>
>> I talked with Wyllys about this on Wednesday and came away with the 
>> conclusion that we could solve the problem much more simply.
>>
>> 1. KMF currently allows for a single trust anchor for each service 
>> (such as Validated Execution). We would want to see this enhanced to 
>> allow more than one trust anchor.
> A:
> I would like to avoid having a file that every new software vendor 
> wants to add themselves to and I also think we may need individual 
> policy properties at some point in the future.  To continue in that 
> fashion I think we would want our policy to split off to new policy 
> per anchor, i.e:
> ta-policy-per-trust-anchor = [true | false]
> In kmf_validate_cert() find_ta_cert() would be passed the issuerDN and 
> find an alternate policy to recursively run itself with.
>

That is not how the KMF policy enforcement works.  The application must 
specify the policy it wants to enforce, KMF will not
try to guess which one to use.


> I.e.:
> The vendor adds their certificate to /etc/certs during software install.
> When we regenerate the initial manifest signedexecadm can detect new 
> unvalidated certificates and offer to create the new policy + new 
> policy file both derived from the DN+serial.

This would work, there are KMF APIs and tools (kmfcfg(1) for updating 
the policy DB.  However, the burden of creating
the new policy is on the signed exec administration tools, KMF is not 
going to automagically do it for you.


>
> B:
> I am concerned about (or don't understand) the current behavior for 
> self signed anchors in kmf_validate_cert().  In the current single TA 
> case I would think they would have to exactly match the TA but it 
> looks like they are allowed unanchored.  In signedexec case they must 
> match a TA.
kmf_validate_cert uses several methods (depending on the policy being 
enforced).

1.  Checks key usage values
2.  Checks EKU values
3. Check validity period
4. Find the TA using the "TA" name /serial specified in the policy
5. Verify that the TA subject DN matches the issuer DN of the cert being 
tested.
6. Verify that the TA cert has the KU_SIGN_CERT bit set (if policy 
requires KU).
7. Verify signature of subject cert using TA public key.


>
>>
>> 2. Either signedexecd needs to get the set of trust anchors from KMF 
>> and validate them with O_VERIFY, or (preferably) KMF needs an option 
>> to open the trust anchor certificates with O_VERIFY.
> It would be hard to dynamically exclude a trust anchor we could not 
> verify if you are suggesting we verify TAs upfront in the first 
> option.  I think we would need to get the "database" (file in 
> openssl's case) from the certificate handle of a specific CA.
> I would greatly prefer the second option.
>
> O_VERIFY also needs to be run on the policy as well.   we could 
> currently be specifying it so we could do it ourselves.  If we make 
> the changes I suggested in (A) kmf would probably need to.

I am not familiar with O_VERIFY - is this a new flag for open(2) ?


>>
>> 3. After KMF verifies a manifest signature, it can report the DN of 
>> the certificate used for signing. Signedexecd can verify that this is 
>> one of the DN's included in /etc/signedexec/certlist (previously 
>> validated with O_VERIFY).
>>
>> I believe that does everything we need. It allows us to
>> (a) verify all trust anchors
>> (b) specify a limited subset of the certificates signed by those 
>> trust anchors that can be used for signing manifests
>> (c) ensure that no one can tamper with any of the certificates 
>> between the trust anchor and the manifest signing certificate
>    I think the current description handles these.  The changes I 
> mentioned handle:
> (d) new TA certificate does not require edit of an existing 
> configuration file/policy.
> (no threat of patches from hell or nightmarish parsing.)

Parsing is handled by KMF, apps never need to parse the KMF policy file, 
it is a private interface.
KMF is not going to dynamically create policy, though, your apps will 
have to deal with that.


> (e) a separate policy per TA is possible
> and this remains cleaner then what I was originally thinking was 
> required.

This is certainly possible today.  Each KMF Policy can have it's own TA.

-Wyllys