Subject: Re: Extended Key Usage and path validation

From: [email-masked] (Peter Gutmann)
Date: Wed, 8 Nov 2000 09:18:57 (NZDT)

[email-masked] (Terry Hayes) writes:

>Since the processing of the EKU extension is intended to provide information
>on both the EE (can it participate in this PKI application) and the CA (can it
>issue the certificate), the extension is checked at all points in the path.
>Except for the trusted anchor all CA certificates in the path must have the
>EKU value corresponding with the current usage.  (Actually, CA certificates
>without and EKU extension are "grandfathered" for SSL and S/MIME, but not
>object signing).  The result is effectively the intersection of the EKU values
>in the path.

I used to do this as well, until someone complained that this was broken since
I was rejecting some otherwise valid certs as invalid.  Reading RFC 2459, I had
to agree that it probably was broken (at least in terms of RFC 2459) since the
EKU would apply to the CA's key, not the keys in the certs it issues.  I think
it's more logical to have it apply to certs it issues, but then you have the
problem that in a CA cert, KU applies to the CA's key and EKU applies to the
issued cert's keys.  Son-of-2459 could do with some added clarification in this
area, although given the current ambiguity and the fact that there appear to be
implementations which have either intepretation, it may be a bit late.  Looks
like the style guide needs an update in this area...

Peter.

---

From: Frank Balluffi <[email-masked]>
Date: Wed, 08 Nov 2000 07:20:44 -0800

Terry Hayes said:

> In fact, I probably could be convinced that Certificate 
> Policies is the correct way of checking the validity of a 
> path for a particular purpose.

Using certificate policies makes a lot of sense, but note that the CA
issuing the end-entity certificate still has some flexibility over what
policy identifiers are included in the end-entity certificate. In the
following example (which I believe to be legal), CA 1 asserts nothing about
signing S/MIME messages:

Issuer  Subject  Policy Identifiers
------  -------  ------------------
CA 1    CA 2     id-foo, id-goo
CA 2    CA 3     id-goo, id-hoo
CA 3    Alice    id-goo, id-smime

In the above example, the most superior certificate is not self signed.

Frank

---

From: Frank Balluffi <[email-masked]>
Date: Wed, 08 Nov 2000 07:35:20 -0800

Note that the following is a very different story:

CA 1    CA 2     id-smime

Frank

> -----Original Message-----
> From: Frank Balluffi [mailto:[email-masked]]
> Sent: Wednesday, November 08, 2000 10:21 AM
> To: [email-masked]'
> Cc: [email-masked]'
> Subject: Re: Extended Key Usage and path validation
> 
> 
> Terry Hayes said:
>

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 14 Nov 2000 16:34:32 -0700

It occurs to me that this discussion is closely related to the attribute certificates discussion.  Here's why.

I'm not sure exactly which particular Extended Key Usage usages are being discussed.  Perhaps the intent is to be generic, and to include even proprietary EKUs, i.e., usages that may be quite useful, but haven't yet reach the point of critical mass to deserve standardization.  But in general it appears that people are trying to use extended key usages to control what amount to privileges, i.e. the right to perform some certain action, or to be believed after such an action is performed

In any case, I believe that the real issue is delegation of control, or vice versa, control of delegation.  My sense is that people are looking for a convenient, easily automated way of determining not only whether a given end entity is entitled to exercise a particular function (with respect to a specified key pair), but whether the CA (or AA) that issued that certificate was itself authorized to delegate that particular function to that end-entity.

The need for this type of delegation control mechanism is precisely why the hierarchical MAC label portion of the Novell Security Attributes (c.f. http://developer.novell.com/repository/attributes/certattrs_v10.htm ) was constructed the way it was -- as a set of security/integrity levels, and perhaps more importantly, as a set of arbitrary capability bits.  By simply ANDiing all of the capability bits of a given type together, from the root cert down to the end entity certificate, it is extremely easy to determine whether every certificate in the chain was duly authorized for that particular attribute.

More to the point, if the RP includes his own "meets minimum" criteria label in that chain of labels, the RP can deny the effective right of some entity to delegate a particular attribute, even if under ordinary circumstances the delegating agency would possess that right.  For example, it is not unusual for two companies to be partners with respect to some particular business matter, and yet competitors with respect to some other matter.  So depending on the context of a particular transaction, the RP might decide whether or not to trust a particular CA, sub-CA, or end entity -- not because of some flaw in the attribute authority itself, or in the end entity, but just because the RP chooses not to trrust that particular attribute in that particular context. 

Whether that particular right is expressed as an attribute certificate, or as an EKU, I believe that there will always be a requirement to be able to control the delegation of that attribute.  Currently, attribute certificates accomplish that by making the RP exercise control over what root AAs are accepted -- an exceedingly blunt instrument in my view.  On the other hand, if no controls are imposed on a CA who issues a certificatee containing a particular EKU, then the only controls are legal/policy, and from a RP software point of view those are effectively unimplementable.

Finally, I do completely agree with the statement that Policy OIDs are NOT the way to accomplish this.  Not only are such policy OIDs not standardized, but the  multiplicity of them would significantly increase the size and complexity of the certificate itself, and of certificate path processing.  I am quite confident of this, because when Dr. Roger Schell (the author of the original orange Book, and my boss at the time) were trying to design this mechanism, I had proposed on OID approach based on familiarity with the Policy OID.  We had some rather heated discussions pro and con, until finally one Sunday afternoon, at the kitchen table at his house, he sketched the MAC label approach, and the light finally went on. Been there and done that, in other words.

Policy OIDs and Policy OID constraints, may have a role to play in enforcing closed PKI user agreements, in particular if the certificate is used in violation of the terms and conditions set down by the CA, or by some governing organization with respect to liability limitations, etc.  (I say may, because I don't believe anyone has yet deployed a meaningful worked example of such constraints being enforced that would demonstrate that fact. But that is a different matter.)

But I am convinced that CP policies would be an absolutely lousy way to try to control the distributed delegation and validation of privileges or rights -- it is simply too hard to do the necessary computations and/or path processing to implement such a scheme in a reasonably effficient access control mechanism.

>>>> "David P. Kemp" <[email-masked]> 11/09/00 09:54AM >>>
>
>> From: [email-masked] (Terry Hayes)
>> 
>> A CA can put this global OID into the CertificatePolicies along with 
>> OIDs for its own more specific or more constrained policies.  The 
>> extension can handle more than one OID.
>> 
>> > [[email-masked]] 
>> > I know the issue here is that we need some technical way to assure that a given
>> > certificate isn't used for something that it was not intended for, but I'm not
>> > sure that either the current method or your proposed fix is the way it should
>> > go. Shouldn't this be something that an attribute certificate be used for, or am
>> > I completely off the mark with that?
>
>
>I agree with Steve Kent that putting an EKU in a CA certificate which does
>not apply to the CA's key is a misusage of that extension.

Me, too.
>
>I agree with Patrick Patterson and Michael Ströder that using the
>Certificate Policies extension to control usage of the EE key
>"messes with" the CP extension.  The policy under which certificates
>are issued seems tenuously related, if not completely unrelated,
>to the applications which make use of the certificates.

Exactly.  They should be used sparingly for legal/policy mechanisms, not to control privileges. (AKA "key usages")
>
>We have basic constraints, name constraints, and policy constraints,
>all of which limit the capabilities of lower CAs and EEs.  And PKIX has
>defined AIA and SIA private (non-X.509) extensions.  If it really is
>necessary for a CA to constrain the usage of an End Entity's key,
>shouldn't we be defining a PKIX-private "EKU Constraints" extension to
>be placed in CA certificates?
>
>I'm not convinced that EKU serves a useful purpose.  And if EKU itself
>is useful, I'm even less convinced that constraining it at the CA
>level, whatever the mechanism, is useful.  If you want EKUs, and you
>don't trust a CA to issue EE certs with proper EKUs, then you shouldn't
>accept the CA.  But if there is a need to use EKU, and to limit it by
>CA, then that need should be satisfied with a clean mechanism, not by
>bastardizing the CP extension.
>
I believe that a mechanism such as the EKU could serve a useful purpose, not as a key usage per se, but rather as a rights management tool.  But in that case we need a compact and easily computable way to control delegation.

Perhaps it is time to rethink these approaches, as we seem to be discovering problem after problem.

Regards,

Bob

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 17 Nov 2000 12:30:59 -0500 (EST)

Steve,

That's the problem with the English language - I used "applications"
in two different senses in the same message, and realized my error
just after hitting "send".

I see two possibilities in your example.  If you mean the application
is "Internet Backbone Management", then I agree that CP is the correct
extension.  S-BGP nodes may be the only planned application of such
certificates, but in the future, the certs might be used for https
connections supporting Internet Management.

But if you mean that the application is "the S-BGP protocol", then I
believe EKU is more appropriate than CP.  S-BGP equipment could require
the presence of an EKU, but it can't require the presence of an
"Internet Management" CP because the equipment might have been
purchased for use in a non-Internet-management environment.

What I should have said is that CP is nearly unrelated to the
protocol which makes use of the certificate.

Regards,
Dave

> Date: Thu, 16 Nov 2000 14:04:43 -0500
> To: "David P. Kemp" <[email-masked]>
> From: Stephen Kent <[email-masked]>
> Cc: [email-masked]
> David,
> There may be examples where the two are aligned. For example, in the 
> S-BGP context, we anticipate defining a CP that clearly restricts the 
> certs issued by registries to be used for S-BGP, as a means of 
> limiting liability.  But, I won't claim that this is a common case.
> 
> Steve