Subject: Re: RFC 5280 and RFC 5055

From: Tom Gindin <[email-masked]>
Date: Tue, 2 Sep 2008 08:55:14 -0400

Santosh:

        The policy constraints extension doesn't work as specified by that 
sentence anyway.  PolicyConstraints has only integer arguments, and can't 
be used to specify an Certificate Policy OID.  We might want to specify 
that permitted-subtrees or excluded-subtrees can, at the RP's discretion, 
be copied to the corresponding variables in 6.1.1.  I do remain dubious 
about the usefulness of CA's having excluded subtrees which are not 
subtrees of permitted ones.
        We can't use the fields within policy constraints for this 
purpose, since they're both bounded integers while the corresponding 
variables in 6.1.1 are booleans.

        Tom Gindin

"Santosh Chokhani" <[email-masked]> 
Sent by: [email-masked]
08/29/2008 09:56 AM

To
<[email-masked]>
cc

Subject
RFC 5280 and RFC 5055

1.       RFC 5280, Section 6.2, states the following:
?For example, a policy constraints extension could be included in the 
self-signed
   certificate to indicate that paths beginning with this trust anchor 
should be trusted only for the specified policies.?  This example should 
be corrected to either point to certificate policies extension or to 
relate the last half of the sentence to the semantics of require explicit 
policy.
 
2.  RFC 5055 should be enhanced to align with 5280.  Aside from replacing 
the references, for example, inputs to path validation may also include 
permitted and excluded subtrees. 
 
Santosh Chokhani
CygnaCom Solutions, Inc,
7925 Jones Branch Drive, Suite 5200
McLean, Virginia 22102
(703) 270-3535
[email-masked]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 2 Sep 2008 09:36:21 -0400

Tom,

I am looking for it to say one of the following:

"For example, a policy constraints extension could be included in the
self-signed certificate to indicate that paths beginning with this trust
anchor 
should be trusted only if the path is valid for a policy"

or

"For example, a certificate policy extension could be included in the
self-signed certificate to indicate that paths beginning with this trust
anchor should be trusted only for the specified policies"

This being an example, is not a big deal.  But, we do not want a
standards track document have inaccuracies.  

-----Original Message-----
From: Tom Gindin [mailto:[email-masked]] 
Sent: Tuesday, September 02, 2008 8:55 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: RFC 5280 and RFC 5055

        Santosh:

        The policy constraints extension doesn't work as specified by
that 
sentence anyway.  PolicyConstraints has only integer arguments, and
can't 
be used to specify an Certificate Policy OID.  We might want to specify 
that permitted-subtrees or excluded-subtrees can, at the RP's
discretion, 
be copied to the corresponding variables in 6.1.1.  I do remain dubious 
about the usefulness of CA's having excluded subtrees which are not 
subtrees of permitted ones.
        We can't use the fields within policy constraints for this 
purpose, since they're both bounded integers while the corresponding 
variables in 6.1.1 are booleans.

        Tom Gindin

To
<[email-masked]>
cc

Subject
RFC 5280 and RFC 5055

be corrected to either point to certificate policies extension or to 
relate the last half of the sentence to the semantics of require
explicit 
policy.
 
2.  RFC 5055 should be enhanced to align with 5280.  Aside from
replacing 
the references, for example, inputs to path validation may also include 
permitted and excluded subtrees. 
 
Santosh Chokhani
CygnaCom Solutions, Inc,

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 25 Sep 2008 06:38:15 +0100

Santosh,

I believe the text in 6.2. of RFC 5280 is correct, but I admit that it can be misunderstood.
The ambiguity lies in the expression "the specified policies".

1.       If this is to mean, the policies provided in the self signed certificate, then it becomes all wrong as the policy constraints extension does not include any policies and because the policy constraints extension does not impose such constraints.

2.       If this, however, is to mean the policies specified by the relying party, then it becomes all correct. Because adding policy constraints (requireExplicitPolicy) forces path validation to fail unless at least one of the set of RP allowed policies are supported.

I read it as the text describes case 2.

Could you elaborate where 5055 should be aligned with 5280?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: den 29 augusti 2008 15:57
To: [email-masked]
Subject: RFC 5280 and RFC 5055

1.  RFC 5280, Section 6.2, states the following:
"For example, a policy constraints extension could be included in the self-signed
   certificate to indicate that paths beginning with this trust anchor should be trusted only for the specified policies."  This example should be corrected to either point to certificate policies extension or to relate the last half of the sentence to the semantics of require explicit policy.

2.  RFC 5055 should be enhanced to align with 5280.  Aside from replacing the references, for example, inputs to path validation may also include permitted and excluded subtrees.

Santosh Chokhani
CygnaCom Solutions, Inc,

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 25 Sep 2008 18:41:37 -0400

Stefan,

An accurate and better way of saying this would be as follows:

"For example, a policy constraints extension could be included in the
self-signed certificate to indicate that paths beginning with this trust
anchor are acceptable only if they are valid for one of the certificate
policies acceptable to the user.  If there is no user acceptable policy,
the path must be valid for a certificate policy."

As to the point regarding aligning 5055, I noticed that 5280 now has the
initial permitted and initial excluded subtrees and 5055, Section 1.4
and associated ASN.1 in 3.2.4 does not.  There may be other areas in
which the two are not aligned.  I did not read 5055 line by line and
carefully, I just noticed this discrepancy.

________________________________

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Thursday, September 25, 2008 1:38 AM
To: Santosh Chokhani; [email-masked]
Subject: RE: RFC 5280 and RFC 5055

Santosh,

I believe the text in 6.2. of RFC 5280 is correct, but I admit that it
can be misunderstood.

1.       If this is to mean, the policies provided in the self signed
certificate, then it becomes all wrong as the policy constraints
extension does not include any policies and because the policy
constraints extension does not impose such constraints.

2.       If this, however, is to mean the policies specified by the
relying party, then it becomes all correct. Because adding policy
constraints (requireExplicitPolicy) forces path validation to fail
unless at least one of the set of RP allowed policies are supported.  

Stefan Santesson

Senior Program Manager

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Santosh Chokhani
Sent: den 29 augusti 2008 15:57
To: [email-masked]
Subject: RFC 5280 and RFC 5055

   certificate to indicate that paths beginning with this trust anchor
should be trusted only for the specified policies."  This example should
be corrected to either point to certificate policies extension or to
relate the last half of the sentence to the semantics of require
explicit policy.

2.  RFC 5055 should be enhanced to align with 5280.  Aside from
replacing the references, for example, inputs to path validation may
also include permitted and excluded subtrees.  

Santosh Chokhani

CygnaCom Solutions, Inc,

McLean, Virginia 22102

(703) 270-3535

[email-masked]