Subject: RE: End-Entity Certificate Policies

From: MHenry <[email-masked]>
Date: Wed, 1 Sep 1999 12:59:10 -0400

Russ,
	The meaning of the sentence " In a CA certificate, these policy
information terms
	    limit the set of policies for certification paths which include
this
    certificate." is not clear to me. Could you explain?

Mike Henry

> -----Original Message-----
> From:	Russ Housley [SMTP:[email-masked]]
> Sent:	Tuesday, August 31, 1999 4:57 PM
> To:	[email-masked]
> Subject:	End-Entity Certificate Policies
> 
> Tim Polk and I got together today to discuss the changes needed to address
> 
> the policy mapping bug (as discussed at the Oslo meeting).  As part of
> this 
> discussion, we discussed the certificate policy extension.
> 
> We believe that a CA certificate may contain one or more certificate
> policy 
> OID.  On the other hand, we believe that an end-entity certificate 
> containing a certificate policy extension must  contain a single 
> certificate policy OID.  RFC 2459 says:
> 
>     The certificate policies extension contains a sequence of one or more
>     policy information terms, each of which consists of an object
>     identifier (OID) and optional qualifiers.  These policy information
>     terms indicate the policy under which the certificate has been issued
>     and the purposes for which the certificate may be used.  Optional
>     qualifiers, which may be present, are not expected to change the
>     definition of the policy.
> 
> We would like to add words to make it more clear that an end-entity 
> certificate may only contain a single certificate policy OID.  The 
> explanation of this extension's purpose in a CA certificate was not
> spelled 
> out, so we propose to fix that too.  Our proposed text is:
> 
>     The certificate policies extension contains a sequence of one or more
>     policy information terms, each of which consists of an object
>     identifier (OID) and optional qualifiers.  In an end-entity
> certificate,
>     these policy information terms indicate the single policy under which
>     the certificate has been issued and the purposes for which the
> certificate
>     may be used.  In a CA certificate,  these policy information terms
>     limit the set of policies for certification paths which include this
>     certificate.  Optional qualifiers, which may be present, are not
>     expected to change the definition of the policy.
> 
> Does anyone disagree?
> 
> Tim and I also discussed certificate policy qualifiers.  Tim and I agree 
> that certificate policy qualifiers should only appear in end-entity 
> certificates.  That is, we agree that certificate policy qualifier should 
> never appear in a CA certificate.  Does anyone (besides Mike Baum)
> disagree?
> 
> Russ

---

From: Bill Burr <[email-masked]>
Date: Thu, 02 Sep 1999 09:57:40 -0400

Sandi,

I don't think that it's obvious what you would do in every case.  In most
cases I suspect that CA's who wished to add a policy OID to a certificate
would first revoke the old certificate, but I don't think that there is
necessarily any reason that they must revoke the existing certificate,
when they add a new policy OID and issue a new certificate.  There may
even be some operational reasons not to revoke the old certificate, so
that old signatures executed with it continue to verify for some period
with a current CRL.

If you need to remove a policy OID from a certificate, then I think that
you have to revoke it and issue another.

I think that a lot of disparate things have been swept under the
certificate policies rug.  Lacking attribute certificates, and given a
state machine for processing certificate policy OIDs in identity
certificates, various folks seem to want to use what they believe they
have now, the certificate policies extension, to solve problems that
might be better addressed by separate attribute certificates.  It looks
to me like Mack's use of certificate policies might well be better
addressed by attribute certificates.  But we don't have attribute
certificate now (nor, truly, do we have many clients today that process
the certificate policies extension).  

At 08:55 AM 9/2/99 -0400, Miklos, Sue A. wrote: 

<excerpt>

<smaller>Please forgive a potentially ignorant question, but I am at a
loss to understand the operational perspective when putting multiple
policy oids (or any attribute values) into a certificate when it is
initially generated and signed.  Is the thought that when an EE gets a
cert, that all of the appropriate policy domains will be known and
populated, in advance?  Will the addition of subsequent oids require
generating new certs (and the accompanying revocation of the 'old'
certs)?

</smaller>

<smaller>Sandi Miklos</smaller> 

<smaller>-----Original Message-----</smaller> 

<smaller>From: Mack Hicks
[<<mailto:[email-masked]>mailto:[email-masked]]</smaller> 

<smaller>Sent: Wednesday, September 01, 1999 11:18 AM</smaller> 

<smaller>To: Sharon Boeyen</smaller> 

<smaller>Cc: 'Charles Moore'; [email-masked]';
[email-masked]'</smaller> 

<smaller>Subject: Re: End-Entity Certificate Policies</smaller> 

<smaller>Sharon,</smaller> 

<smaller>I agree with you. I have a real business need for multiple OIDs
in an End Entity</smaller> 

<smaller>Certificate.</smaller> 

<smaller>In the Identrus community, all certificates under the Identrus
Root must have</smaller> 

<smaller>the OID of Identrus. It is expected that relying parties may be
receiving</smaller> 

<smaller>certificates from multiple participants and sub-CAs within the
structure. It is</smaller> 

<smaller>easier for the relying party to be able to identify an Identrus
certificate and</smaller> 

<smaller>its context of use through the Identrus OID. Restricting the
number of OIDs</smaller> 

<smaller>means that the relying party has no way of determining a
membership in a broader</smaller> 

<smaller>community. Further, the sub-CAs have no way for providing
further policy context</smaller> 

<smaller>of an end-entity certificate. (I realize that cert path
validation would</smaller> 

<smaller>identify these communities, but the relying party may not have
all the</smaller> 

<smaller>certificates in the path.)</smaller> 

<smaller>I do not see the any advantage to mandating  only a single OID
in an EE</smaller> 

<smaller>certificate. From a business view, the result is to proliferate
the number of</smaller> 

<smaller>policy documents.</smaller> 

<smaller>Mack Hicks</smaller> 

<smaller>Sharon Boeyen wrote:</smaller> 

<smaller>> I don't support limiting to a single policy OID or limiting
the use of</smaller> 

<smaller>> qualifiers only to end-entity certs. Even if this was agreed
as part of</smaller> 

<smaller>> the PKIX profile for what CAs were to do, relying parties
presumably would</smaller> 

<smaller>> need to be able to deal with certs that were created outside
of PKIX and</smaller> 

<smaller>> these might very well have multiple policies in the end-entity
certs and</smaller> 

<smaller>> qualifiers in the CA certs. So at best this proposal might
impose limits</smaller> 

<smaller>> on CA behavior for PKIX CAs, but probably couldn't on PKIX
relying parties</smaller> 

<smaller>> unless we want to isolate the PKIX world from the rest of the
world :-(</smaller> 

<smaller>></smaller> 

<smaller>> Sharon</smaller> 

<smaller>></smaller> 

<smaller>--</smaller> 

<smaller>-------------------------------------------------------------------</smaller> 

<smaller>Mack Hicks, VP     [email-masked]</smaller> 

<smaller>Bank of America  +1-415-436-5809</smaller> 

</excerpt><<<<<<<<

Regards,

Bill Burr

---

From: [email-masked]
Date: Thu, 2 Sep 1999 12:12:21 -0400

Just adding my voice to the chorus - I'd strongly object to limiting EE certs 
to a single policy OID.  One of the planned deployment models uses policy OIDs 
as applicability labels (OK for email; OK for transactions; Ok for intranet 
access; OK for online banking; etc.)  These policy OIDs may well be 
standardized across multiple issuers/organizations.  Thus, a given cert may 
well have multiple such OIDs present (loosely like having multiple card network 
logos on the back of your ATM/credit card) if approved for multiple purposes.  
This model also makes RP configuration much simpler.  

As to policy qualifiers, you can deprecate them everywhere as far as I'm 
concerned.

Dave

> From: housley [mailto:[email-masked]]
> To: ietf-pkix
> Cc: housley
> the policy mapping bug (as discussed at the Oslo meeting).  
> As part of this 
> We believe that a CA certificate may contain one or more 
> certificate policy 
> explanation of this extension's purpose in a CA certificate 
> was not spelled 
>     identifier (OID) and optional qualifiers.  In an 
> end-entity certificate,
>     the certificate has been issued and the purposes for 
> which the certificate
> never appear in a CA certificate.  Does anyone (besides Mike 
> Baum) disagree?
> 
> Russ
>

---

From: Charles Moore <[email-masked]>
Date: Fri, 3 Sep 1999 06:45:55 +1000

-----Original Message-----
From: Miklos, Sue A. [mailto:[email-masked]]
Sent: Thursday, 2 September 1999 22:56
To: 'Mack Hicks'; Sharon Boeyen
Cc: 'Charles Moore'; [email-masked]'; [email-masked]'
Subject: RE: End-Entity Certificate Policies

Please forgive a potentially ignorant question, but I am at a loss to
understand the operational perspective when putting multiple policy oids (or
any attribute values) into a certificate when it is initially generated and
signed.  Is the thought that when an EE gets a cert, that all of the
appropriate policy domains will be known and populated, in advance?
[Charles Moore] Two assumptions: a) that the certificate policies directly
relate to the business activities being supported, and hence it is
reasonable that the CP(s) are known ( supporting an unknown business s
process sis difficult at best). b) the certificates are part of an
infrastructure, not really stand alone, c) that a certificate is no more
difficult to manage than say a password.  This discussions are not just
limited to certificates for the purposes of ID.

The use of policy qualifiers reduces the need for multiple EE policies.
Weather one has single or multiple CP (oids) or one CP with several Policy
qualifiers is a business and system design issue, not a PKIX one...

  Will the addition of subsequent oids require generating new certs (and the
accompanying revocation of the 'old' certs)?
[Charles Moore] Generation yes, revocation depends on the business  and
usage..

 Start with the basis that certificates are not useful on their own, and
most things fall into place...

Sandi Miklos 

-----Original Message----- 
From: Mack Hicks [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Wednesday, September 01, 1999 11:18 AM 
To: Sharon Boeyen 
Cc: 'Charles Moore'; [email-masked]'; [email-masked]' 
Subject: Re: End-Entity Certificate Policies 

Sharon, 

I agree with you. I have a real business need for multiple OIDs in an End
Entity 
Certificate. 

In the Identrus community, all certificates under the Identrus Root must
have 
the OID of Identrus. It is expected that relying parties may be receiving 
certificates from multiple participants and sub-CAs within the structure. It
is 
easier for the relying party to be able to identify an Identrus certificate
and 
its context of use through the Identrus OID. Restricting the number of OIDs 
means that the relying party has no way of determining a membership in a
broader 
community. Further, the sub-CAs have no way for providing further policy
context 
of an end-entity certificate. (I realize that cert path validation would 
identify these communities, but the relying party may not have all the 
certificates in the path.) 

I do not see the any advantage to mandating  only a single OID in an EE 
certificate. From a business view, the result is to proliferate the number
of 
policy documents. 

Mack Hicks 

Sharon Boeyen wrote: 

> I don't support limiting to a single policy OID or limiting the use of 
> qualifiers only to end-entity certs. Even if this was agreed as part of 
> the PKIX profile for what CAs were to do, relying parties presumably would

> need to be able to deal with certs that were created outside of PKIX and 
> these might very well have multiple policies in the end-entity certs and 
> qualifiers in the CA certs. So at best this proposal might impose limits 
> on CA behavior for PKIX CAs, but probably couldn't on PKIX relying parties

> unless we want to isolate the PKIX world from the rest of the world :-( 
> 
> Sharon 
> 

-- 
------------------------------------------------------------------- 
Mack Hicks, VP     [email-masked] 
Bank of America  +1-415-436-5809

---

From: [email-masked]
Date: Thu, 2 Sep 1999 20:55:15 EDT

I would like to add my/our voice(s)in support of Dave's and Mack's responses.

We strongly resist the idea of restrictions.  Our community has some deployed 
infrastructure and proposed services that absolutely rely upon multiple 
policy OIDs.  In some cases it is helpful, in many other cases it is 
imperative that they be supported.  (full disclosure-some of my projects 
require this as well)

After a painful, but terribly productive last two days at the ANSI X9F5 
meeting at the ABA's offices it was discomforting to see the first parts of 
this thread.

I was very pleased to see that the response from the banking community.  
Historically it has been extremely helpful to many folk involved in policy 
making and standards setting to review the concrete requirements from 
communities such as Identrus, SWIFT, and ABAecom as well as the deployed 
infrastructures run by financial institutions in the wild.  Having those 
requirements accessible directly or through participation in discussions like 
these is essential to finding solutions that actually work and meet real 
needs.  

I would encourage everyone to take great care to determine whether proposals 
would cause already deployed systems to become unsupported or render them 
noncompliant.

I have more specific arguments if anyone would like to hear them.

...Kawika Daguio...

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 3 Sep 1999 10:28:06 -0400 (EDT)

Isn't the extended key usage extension present for precisely the purpose
of containing "applicability label" OIDs?

> From: [email-masked]
>

---

From: Michael Myers <[email-masked]>
Date: Fri, 3 Sep 1999 00:18:32 -0700

Russ,

For clarification of my position, I am observing that the jurisdictional
authority under which a cross-certificate was issued to an existing CA may
differ from the jurisdictional authority governing issuance of end-entity
certificates intended to validate beneath that cross-certificate.

Two such jurisdictions may be represented by, among other things, different
certificate policy OIDs.  To the extent that a certificate policy OID maps
directly to a CPS, it follows that the qualifer used to point to these CPSs
would likewise differ.

Since a cross-certificate is by definition a CA certificate, it follows that
2459 must permit a CA certificate to contain a CPS pointer.

Mike

> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, September 02, 1999 12:33 PM
> To: [email-masked]
> Mike Myers suggests that CA certificates should be permitted 
> to include the CPS pointer qualifier.  Let's assume that
> there is a simple path of two certificates, the CA certificate
> and the end-entity certificate.  The CA  certificate has two
> certificate policy OIDs, each with a CPS pointer qualifier.
> The end-entity certificate has a single certificate policy OID, 
> also with a CPS pointer qualifier.  When the certificate path 
> validation algorithm is executed, one of the outputs will be
> the certificate policy OID that is common to both certificates
> and the two qualifiers (one from the CA certificate and one
> from the end-entity certificate).  What is the  certificate
> user expected to do?  If the URLs are different, the 
> certificate user really has no idea what to do.
> 
> Russ
>

---

From: Russ Housley <[email-masked]>
Date: Tue, 07 Sep 1999 09:33:31 -0400

Bill:

 >>Single Certificate Policy OID
 >>
 >>When an end-entity certificate contains more than one certificate policy
 >>OID, there is ambiguity about the intent of a signer.  On the other hand,
 >>if the end-entity certificate contains only one certificate policy OID,
 >>there is no ambiguity.  If an end-entity certificate contains two policies,
 >>one that says the certificate id for use with non-binding e-mail and
 >>another that says the certificate is intended for purchases up to $10,000,
 >>then it is not clear the signer intends when a signature is generated.
 >
 >But, is it clear that one CP will necessarily be that specific?  A single
 >policy  might allow several applications, or it might speak to assurance
 >level rather than constraining applications at all.
 >
 >Moreover, when I sign something with my John Hancock, do I state the policy
 >under which I sign it, and have a separate signature for every kind of
 >document I sign?  Why do I have to with certificates?  And, is it your
 >supposition that the certificate used to sign a document is always bound
 >with the signed document?

This question was debated quite a bit in the ietf-smime list.  Denis Pinkas 
was the major advocate for a mechanism that allowed a signer to bind the 
certificate that she expected to be used to verify the signature to the 
signed content.  RFC 2634, Section 5.4 is the result of that discussion.

Some certificate policies will include statements that limit the types of 
transactions for which the certificate is appropriate. SET is one existing 
example.  A SET certificate should not be considered valid for signing 
S/MIME messages.  On the other hand, there are policies that do not include 
such constraints.  Verisign Class 1 is one example.  It is up to the signer 
to use a private key that corresponds to an appropriate certificate when 
signing.  If the signer does not, then the recipient will not consider the 
signature valid.

Russ