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

[Patrick.Patterson@xxxxxxxx]

I'll second the confusion:

but for a slightly different reason: Having both Certificate Policy OIDs (that
tie a given X.509 Certificate to a given Certificate Policy) and Usage Policy
OID's (which is what I think these should be correctly called) mixed in the same
extension is a "Bad Thing" in my opinion - a given Certificate Policy should
state categorically what is an allowed function, and what is not an allowed
function. I guess that I don't see how the "mix and match" scenario would be
written into the policies - "You can write e-mail all of the time, but only
certificates issued on the third monday of the month may have the purchasing
flag extended" - I'll admit that this is an extreme example, but in my mind - if
you want a certificate to be usable for different things, create them under
different policies (and thus different OIDs)  - to borrow the analogy from
below: have Lax and E-mail be one certificate policy, and strict and purchasing
be another.

This still doesn't address the idea where all of this started: The need to have
some way of having an application check for usage validity of a given
certificate type, but I'm going to hold to my position that the Certificate
Policy field is not the place to do this.

Patrick.
________________________________________________________________________________________

>From Marc Branchaud <marcnarc@xcert.com> on 9 November 2000 7:07:54 PM
To : ietf-pkix@imc.org
Copy To : (bcc: Patrick Patterson)
Subject : The CP Extension (was Re: Extended Key Usage and path validation)



"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/
+------------------------------------------------------------------------+

------
Patrick Patterson
PKI Expert, IPVAS CA
SITA/Equant JV.