Subject: RE: SkipCerts Question [RFC3280]

From: Sharon Boeyen <[email-masked]>
Date: Thu, 27 Feb 2003 10:05:19 -0500

Santosh, I wasn't aware there was a difference. If there is we need to
resolve 
that somehow. The X.509 text was changed via DR 222 against the 97 edition.
That 
was the big DR that completely replaced the path processing text in 509 to
address 
a number of primarily policy-related issues. I'm not sure I still have all
the 
history of ballot comments etc, but I'm fairly sure that one of our goals
was 
alignment between PKIX and 509 at the time. 

To try to clarify exactly what the difference is, do you agree with the
following?

a) If the final intermediate cert in the path causes the count to reach
zero, the existence 
   of an end certificate causes the path to be rejected in both 509 and PKIX
if there isn't 
   at least one acceptable policy in all certs in the path.

If that is true, then as long as the final certificate in the path is always
treated as an 
end certificates, as opposed to an intermediate certificate, I don't believe
there is any 
misalignment between PKIX and 509. Am I missing something or do we just need
to clarify that 
the final cert in a path is always treated treated as an end certificate
regardless of whether 
it is a CA cert or an EE cert? 

Cheers,
Sharon

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, February 26, 2003 8:53 PM
To: 'Sharon Boeyen'; 'n Russ Housley'
Cc: [email-masked]; [email-masked]
Subject: RE: SkipCerts Question [RFC3280]

Sharon:

I do not understand your first point.  Are you saying that X.509 will be
changed to align with 3280 and in that case skipCerts = 0 for
requireExplicitPolicy will also take effect in the next certificate?  Or,
are you saying that the difference between 3280 and X.509 will remain?  I
assume you agree that I am reading 3280 correctly.

BTW, on the second point, I meant to say that the trust anchor issues a CA
certificate and the CA  is acting as an end entity and we want the
requireExplicitPolicy to take affect immediately. 

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Wednesday, February 26, 2003 4:37 PM
To: [email-masked]'; n Russ Housley
Cc: [email-masked]; [email-masked]
Subject: RE: SkipCerts Question [RFC3280]

Santosh I agree with you that the extension in cert 1 with a skip certs
value of 1 DOES 
mean that the existence of cert 2 in the path reduces the skip certs value
to 0 and the 
constraint takes effect immediately. This is not in contradiction with X.509
however, as 
a Defect Report was issued that aligned the two. The last time I looked at
the wording 
in 509 however, I noticed that 2 additional changes are needed and submitted
a new DR 
to the London meeting to fix them. I wasn't at the London meeting however
and don't know 
what happened to the DR yet. 

However, one point I disagree with is with respect to your example of
End-Entity certificates. If a trust anchor is issuing EE certs directly
there is no certificate that they could include the policy constraints
extension in. It is only permitted in CA certificates. EE certs however 
DO decrement the value of the skip certs for requiresExplicitPolicy and as
such can have an 
effect on whether or not the policy is required. 509 did, as part of the
original DR make that 
change to allow them to decrement the count, but did not change the
requirement that the extension 
only be permitted in CA certs. 

Note, that this is the ONLY place where skipCerts is treated this way. For
inhibitPolicyMapping and 
inhibitAnyPolicy, they take effect on subsequent certificates only, not the
one that causes the 
count to reach zero and the certificates that need to align with the
constraint are ONLY those that 
are subsequent to the zero count, whereas with requiresExplicitPolicy it is
ALL certs in the path 
including those (if any) prior to the zero count being reached.

Cheers,
Sharon 

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Friday, February 21, 2003 4:47 AM
To: n Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: SkipCerts Question [RFC3280]

Kozo and Russ:

Both of your e-mails are ambiguous to me.

Let me try to provide a clear answer and hopefully it will relate 
to the question being asked.

1.  For require explicit policy, the skipCerts starts applying to 
the certificate in which the value is asserted.  3280 is in contradiction 
in this area with X.509.  The reason it was done is so that in a 
case where trust anchor issues end entity certificates, the infrastructure 
can control turning on of this feature.

2.  DFor requireExpliclityPolicy once a value of zero is reached, requires a
common policy in each certificate (taking policy mapping 
into consideration).  Furthermore, if user initializes the path validation 
with one or more policies (other than anyPolicy), at least one of 
the user policies must appear in each certificate (again taking policy 
mapping into consideration).

3.  3280 is incomplete in the area of processing requireExplicitPolicy 
related stuff.  Specifically, it does not define how there is policy 
failure due to the requireExplicitPolicy being set.

In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But,
since skipCert applies to cert1, by the time cert2 is processed,
requireExplicitPolicy flag is set and all three certiifcates cert0, cert1,
and cert2 must have at least one common policy asserted. 
In addition, if user initialized the path processing with some explicit 
policy(s), at least one of those policies must be common to all three 
certificates.

Any other interpretation by 3280 makes 3280 inconsistent with X.509 
in the area of policy processing.

At Thursday, 20 February 2003, Russ Housley <[email-masked]> 
wrote:

>Kozo:
>
>You understand correctly --  cert2 is not required to have an explicit
policy.
>
>Russ
>
>At 07:45 PM 2/17/2003 +0900, [email-masked] wrote:
>
>>Dear all,
>>
>>We are now testing our certificate path validation
>>program in Japan.
>>And I have a question on the "SkipCerts" in the RFC3280.
>>
>>Would you please tell me?
>>
>>-----
>>According to the RFC3280,
>>
>>4.2.1.12  Policy Constraints
>>
>><snip>
>>
>>If the requireExplicitPolicy field is present, the value of 
>>requireExplicitPolicy indicates the number of additional certificates 
>>that may appear in the path before an explicit policy is required for 
>>the entire path.
>>-----
>>
>>If there is a certificate path like the following,
>>   cert0
>>   cert1
>>   cert2
>>
>>and if the cert1 has the requireExplicitPolicy=1,
>>
>>is the cert2 required to have an explicit policy or not ?
>>
>>(Is the value applied to the cert1
>>  which has the requireExplicitPolicy=1?)
>>
>>I don't think the cert2 is required to have it,
>>but I'm not sure.
>>
>>Regards,
>>  Kozo
>>--------------------------------------------------------
>>Kozo FUJINO (TEL: +81-82-264-8544  FAX: +81-82-264-8549)
>>NEC System Technologies, Ltd.
>>Hiroshima, Japan
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 27 Feb 2003 10:15:29 -0500

Sharon:

My reading is very simple.  My reading is as follows and it applies in
general and not just to the last certificate in chain or other esoteric
stuff.

2000 edition of X.509 starts applying the skipCerts for
requireExplicitPolicy to the certificate in which it is asserted.

3280 applies the skipCerts for requireExplicitPolicy to the next
certificate.

For example, in the example Kodo cited (and in a private e-mail he agreed
with me), 3280 will not require explicit policy for the path and X.509 will.
The reasons are articulated in this thread by me. 

I will call you to discuss this.

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Thursday, February 27, 2003 10:05 AM
To: 'Santosh Chokhani'; Sharon Boeyen; 'n Russ Housley'
Cc: [email-masked]; [email-masked]
Subject: RE: SkipCerts Question [RFC3280]

Cheers,
Sharon

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, February 26, 2003 8:53 PM
To: 'Sharon Boeyen'; 'n Russ Housley'
Cc: [email-masked]; [email-masked]
Subject: RE: SkipCerts Question [RFC3280]

Sharon:

-----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]] 
Sent: Wednesday, February 26, 2003 4:37 PM
To: [email-masked]'; n Russ Housley
Cc: [email-masked]; [email-masked]
Subject: RE: SkipCerts Question [RFC3280]

Cheers,
Sharon 

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Friday, February 21, 2003 4:47 AM
To: n Russ Housley
Cc: [email-masked]; [email-masked]
Subject: Re: SkipCerts Question [RFC3280]

Kozo and Russ:

policy.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 27 Feb 2003 11:21:09 -0500

>assume you agree that I am reading 3280 correctly.
Santosh,

X.509 and RFC 3280 both state that if a certificate includes 
requireExplicitPolicy with skipCerts = 0, the constraint takes effect 
immediately.

In X.509, this can be seen in the following statements:

Clause 10.5.3:
    For all certificates, the following actions are then performed:

    a)  If explicit-policy-indicator is not set:

        If the requireExplicitPolicy constraint is present in the 
certificate, perform the
        following.  For a SkipCerts value of 0, set the 
explicit-policy-indicator.

Clause 10.5.4:
    For the end-certificate, the following actions are then performed:

        a)  If explicit-policy-indicator is set, check that the 
authorities-constrained-policy-set table is not empty.
        (NOTE: As a result of DR 289, X.509 now requires that one also 
check that the user-constrained-policy-set
        is not empty).

In RFC 3280:

section 6.1.4 (processing of intermediate certificates):

      (i)  If a policy constraints extension is included in the
      certificate, modify the explicit_policy and policy_mapping state
      variables as follows:

         (1)  If requireExplicitPolicy is present and is less than
         explicit_policy, set explicit_policy to the value of
         requireExplicitPolicy.

section 6.1.5 (wrap-up procedure):

      (b)  If a policy constraints extension is included in the
      certificate and requireExplicitPolicy is present and has a value
      of 0, set the explicit_policy state variable to 0.

   If either (1) the value of explicit_policy variable is greater than
   zero, or (2) the valid_policy_tree is not NULL, then path processing
   has succeeded.

So, in both cases, if requireExplicitPolicy is present with SkipCerts=0, 
even in the final certificate in the path, then the path will be 
rejected unless it is valid under at least one user acceptable policy. 
 The two documents also agree on the processing requirements when 
skipCerts > 0.

When Sharon mentioned a new defect report against X.509, she was 
referring to the text in clause 8.4.2.3 that describes the 
policyConstraints extension.  There was concern that this text was 
somewhat ambiguous.  The text in clause 10, which provides detailed, 
step-by-step, processing requirements for the fields in the 
policyConstraints extension will not be changed.

There is, however, one place in which X.509 and RFC 3280 diverge in the 
processing of the requireExplicitPolicy field of policyConstraints.

X.509 states in clause 10.5.3:

    if the explicit-policy-pending indicator is set and the certificate 
is not a self-issued intermediate certificate,
    decrement the corresponding skip-certificates value and, if this 
value becomes zero, set explicit-policy-indicator.

RFC 3280 states in section 6.1.5 (prcessing of the final certificate in 
the path):

      (a)  If certificate n was not self-issued and explicit_policy is
      not 0, decrement explicit_policy by 1.

Thus, in X.509 a self-issued end certificate counts when determining 
whether the path is long enough to "turn on" the constraint. In RFC 
3280, a self-issued end certifcate does not count.

Since, as a general rule, self-issued end certificates are treated the 
same as certificates that are not self-issued, I believe this was an 
error in RFC 3280.

Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 27 Feb 2003 15:55:59 -0500

David:

As Sharon notes, the text in the description of the extension needs to
change.  It will also nice to note that if skipCert < = 0 and
valid_policy_tree = null, there is policy failure.

I will propose some changes to both sections.  The first one in my mind is a
must (i.e., the description of the extension).  The second one (i.e., in the
path validation) is to simply add clarity that other wise path validation
fails.  I will propose some text later in response to Sharon's e-mail.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Thursday, February 27, 2003 11:21 AM
To: [email-masked]
Subject: Re: SkipCerts Question [RFC3280]

Santosh Chokhani wrote:

>I do not understand your first point.  Are you saying that X.509 will 
>be changed to align with 3280 and in that case skipCerts = 0 for 
>requireExplicitPolicy will also take effect in the next certificate?  
>Or, are you saying that the difference between 3280 and X.509 will 
>remain?  I assume you agree that I am reading 3280 correctly.
>
Santosh,

Clause 10.5.3:

Clause 10.5.4:

In RFC 3280:

Dave

---

From: [email-masked]
Date: Fri, 28 Feb 2003 10:50:55 +0900

Santosh:

According to the RFC3280,
 after decrementing explicit_policy,
 the value would be reset.

Therefore if some changes are needed,
the following also need to be changed.

Thank you,
 Kozo

-----
6.1.4  Preparation for Certificate i+1

<snip>

(h)  If the issuer and subject names are not identical:

    (1)  If explicit_policy is not 0, decrement explicit_policy by 1.

<snip>

-----Original Message-----
From:"Santosh Chokhani" <[email-masked]>
Date:Thu, 27 Feb 2003 15:55:59 -0500
Subject:RE: SkipCerts Question [RFC3280]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 27 Feb 2003 22:57:35 -0500

Kozo:

Based on your comment, I have reviewed the path validation sections you cite
in 3280.  These sections seem to be correct to me.  The first one is
decrementing the counter.  The second one is taking the low water mark of
the pending constraint and the constraint imposed in the new certificate.  I
also think the order is correct, i.e., the pending counter should be
decremented before taking the low water mark of the current state variable
and the new constraint.

Please tell me what part is wrong?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 27, 2003 8:51 PM
To: [email-masked]
Cc: Santosh Chokhani; [email-masked]
Subject: RE: SkipCerts Question [RFC3280]

Santosh:

Thank you,
 Kozo

-----

<snip>

<snip>

-----Original Message-----
>I will propose some changes to both sections.  The first one in my mind
>is a must (i.e., the description of the extension).  The second one
>(i.e., in the path validation) is to simply add clarity that other wise
>path validation fails.  I will propose some text later in response to
>Sharon's e-mail.
>
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of David A. Cooper

---

From: [email-masked]
Date: Fri, 28 Feb 2003 13:58:29 +0900

All:

I'm very sorry.
I found my misunderstanding.

During the "Basic certificate Processing" (e)
 valid_policy_tree truns NULL.

During the "Wrap-up" (a),
 the counter turns 0.

So the path processing fails.

Therefore the cert2 is required to have an explicit policy.

       cert0
       cert1:requireExplicitPolicy=1
       cert2

Thank you very much,
 Kozo

-----Original Message-----
From:"Santosh Chokhani" <[email-masked]>
Date:Thu, 27 Feb 2003 22:57:35 -0500
Subject:RE: SkipCerts Question [RFC3280]

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 28 Feb 2003 17:11:35 +0100

All,

It seams that I mixed up the cut-off dates for Internet drafts submission 
and submitted the 00 draft on son of RFC 3039 (Qualified Certificates 
Profile) to late.

So I do the second best thing and make the draft available from my own web 
site until it hits the PKIX charter page.

You can get the preliminary draft from:
http://216.219.254.34/retrospekt.com/pages/2/index.htm

The only changes from RFC 3039 is:
  - Clarification of scope
  - Title attribute is moved from subjectDirectoryAttribute to the Subject 
field
  - Requirement to set non-repudiation exclusively if set is removed as a 
SHOULD requirement and left to local profiling.
  - Old references to RFC 2459 are updated to RFC 3280

The intention so far is to limit changes to editorial changes.

The rationale behind these updates are:

1) Clarification of scope
There are numerous if implementations that use RFC 3039 without issuing the 
certificates as Qualified Certificates. Especially the conventions 
regarding use of attributes in the subject field are of general value. The 
clarification of scope express more clearly than before that this standard 
can be used for any ID-certificate issued to humans and further includes 
mechanisms related to Qualified Certificates. This was true also with RFC 
3039 but not so clearly expressed.

2) Title attribute
Suggesting that this attribute should be placed in subject Directory 
attributes was a bad choice that no implementation that I know of has 
followed. Likewise, many applications that need to use the title attribute 
do not support use of subjectDirectoryAttributes. Use of the title 
attribute is common and use of subjectDirectoryAttributes is rare: This is 
a bad mix.

3) Non-repudiation.
This change does not make any contribution to the meaning of this key usage 
declaration, but it suggest that this profile is the wrong place to have 
any opinion on whether this key usage bit should be set exclusively or not. 
The draft suggest that national legislation and local policies have to 
decide this as long as the meaning of the bits are consistent with RFC 3280.

It should also be noted that Tim and Magnus has agreed to co-edit this 
document but they have not yet had the time to fully review this first 
draft so don't hit on them yet for things you don't like.

Any comments and suggestions are welcome

I'll be in San Francisco as well.

/Stefan