[kmf-discuss] Certificate management

[Will Young]

Wyllys Ingersoll wrote:
> 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.

Right, I was suggesting we have a signed_exec policy which is all we'd 
ever feed KMF.  But this policy would have a more complex TA 
configuration that sets up a rule for KMF to find a TA specific policy 
based on issuerDN.

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

	This is not what I was suggesting, rather signedexec would create one 
"unmodifiable" signed exec policy with a rule to find TA specific 
policies based on the signer.  The other policies would be 
added/verified dynamically by the initial manifest signer with 
signedexec as software adds CAs.

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

	It looks to me like this is saying the TA is irrelevant to self signed 
certs which means the way around needing to honor the trust anchor is 
creating a bogus self signed cert.  If there is nothing establishing the 
legitimacy of the CA other than its matching DN that may not matter but 
if we add an independent reason to trust it's legitimacy (we O_VERIFY 
its certificate) then a self_signed must have a issuerDN matching the TA 
(and therefore be the TA.)
> 
>>
>>>
>>> 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) ?

	Yes the signed exec project adds the O_VERIFY flag, at initial startup 
of signedexecd an open succeeding with O_VERIFY would indicate that the 
file was hashed in the initial manifest (which has hopefully been 
secured by a TPM.)
> 
> 
>>>
>>> 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.

	Yes, so we are shipping signedexec which needs to ship a policy.  As 
products are added they will need the ability to add certificates (i.e. 
to /etc/certs) and to add TAs.  I would prefer that they do this purely 
by adding new files that are valid once they are verifiable (i.e. added 
to the initial manifest.)

	If they do this by modifying the existing signed_exec policy file they 
will invalidate it, making the entire system unverifiable until the 
initial manifest signer is available next.
> 
> 
>> (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.
So this would mean given a signer cert we do:
policyfile = str_to_policy(kmf_get_cert_issuer_str(cert))
open (policyfile, O_VERIFY)
kmf_initialize( h, policyfile, policyfile*)
   (*if we use a static name all signed policies will be interchangeable)
keystore = kmf_configure_keystore(h )
kmf_validate_cert (cert, *attributes= {keystore,...})
where using O_VERIFY is either a new attribute in attributes or a new
property in the policy.

This would imply there's no need for a default signed_exec policy file
but rather is a directory of policies in /etc/signedexec.

I'm not sure that the independent open can be used to guarantee the
policy remains verifiable throughout.

This would imply there can be no middle tier between signedexec and kmf
since the operations are too specific.

	This seems to be getting very complicated.


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