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

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

> From: Marc Branchaud <marcnarc@xcert.com>
> 
> 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.


X.509 says:

    Typically, different certificate policies will relate to different
    applications which may use the certified key.

and the example under policy mappings refers to policies for "Canadian Trade",
"U.S. Trade", and "North American Trade".

This example coincides with my impression that the "purposes" referred
to in new-part1 and the "applications" in X.509 are things which are
specific to a business domain (banking, DoD, Xcert, VeriSign) rather
than things which are specific to communication protocols (email, web,
VPN, ...).  If you refer to issuing practices and usages,
"International Trade" or "Organization A" would be the usage, which
specifies a policy domain under which "lax" and "strict" are defined.
Under this interpretation, usage and assurance are not orthogonal;
Organization B might have a significantly different definition of "lax".

Perhaps it would be less ambiguous if new-part1 said:

   In an end-entity certificate, each policy information term indicates
   the policy under which the certificate has been issued and the purposes
   for which the certificate may be used.
   
instead of:

  In an end-entity certificate, these policy information terms indicate ...

That would make it clear that there can be more than one term, but each
term indicates both a certificate policy and some purposes under that policy.



> 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 agree that "purchasing" might be a purpose, but I don't agree that
"login" and "email" are the purposes envisioned by Certificate
Policies.  You can conduct purchasing transactions over email, over the
web, over IPsec connections, or through an EDI VAN.  Purchasing also
might involve both confidentiality and signatures.  The low-level OS
operations (login), communication protocol (email) and crypto functions
(signature) are controlled by KU/EKU.  The business-level purposes
(purchasing less than $10K, access to grade-B sensitive information,
...) are the ones which a Certificate Policy is intended to address.

A rule of thumb might that KU/EKU specifies things which could be be
wired into a generic toolkit, but CP specifies things which must be
decided by application-specific code.