The CP Extension (was Re: Extended Key Usage and path validation)

[Marc Branchaud <marcnarc@xxxxxxxxx>]

"David P. Kemp" wrote:
> 
> 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.
> 

OK, I'm confused.

Section 4.2.1.5 of draft-ietf-pkix-new-part1-02.txt states:

   In an end-entity certificate, these policy information terms indicate
   the policy under which the certificate has been issued and the pur-
   poses for which the certificate may be used.  In a CA certificate,
   these policy information terms limit the set of policies for certifi-
   cation paths which include this certificate. When a CA does not wish
   to limit the set of policies for certification paths which include
   this certificate, they may assert the special policy anyPolicy, with
   a value of {2 5 29 32 0}.

I take this to mean that the CP extension is specifically about both
certification practices (i.e. cert issuing policy) _and_ certificate use.  I
see nothing here that says you can't use a CP extension in a CA cert to limit
the uses of subsequent certs in a chain.

> We have basic constraints, name constraints, and policy constraints,
> all of which limit the capabilities of lower CAs and EEs.

I disagree with you here about the policy constraints extension.  That
extension merely sets limits on the extent to which policies are applied in
chain processing, but it does _not_ explicitly define or limit any
capabilities.

It seems to me that cert usage limitations are all supposed to be expressed
in the policies extension.  Indeed, I expect that most deployments would
define separate policy OIDs to represent both issuing practices and usage
policies, because the two are quite orthogonal.  An organization might, for
example, have "lax" and "strict" issuing processes, and might have three uses
for its certificates ("login", "email" and "purchasing").  For whatever
reasons, it may want to be able to mix & match issuing processes with uses
("lax" with "login", or "strict" with "purchasing").  All this is supposed to
be expressed through OIDs in the CP extension.

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

Both EKU and CP are quite similar (one's just an OID, the other's just an OID
with some qualifying info).  I tend to agree that EKU is currently a bit
redundant, but it seems to me that having two different extensions to address
issuing and usage policies might be a good thing.  EKU seems a good candidate
to identify the usage policies, leaving CP solely for issuing policies.  This
would require, as you say, a new mechanism ("EKU Constraints extension"
perhaps?) to manage the EKU policies.  There would also have to be an
understanding, I think, that a CA with, say, an "email" usage OID only means
that the CA is allowed to issue certs with that OID (not that the CA can
somehow be used for signing S/MIME messages).

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 marcnarc@xcert.com        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+