Subject: Re: Extension name divergence between PKIX profile and X.509 4th Edition

From: "David A. Cooper" <[email-masked]>
Date: Wed, 11 Apr 2001 17:30:33 -0400

Carlin,

This is something that was briefly discussed on the list in early March (see messages with the subject "RE: WG Last Call: Son-of-2459: More about delta-CRLs" in the mail list archive). I don't think there is any problem with what PKIX has done. PKIX has simply chosen (1) not to include the deltaInfo extension in its profile and (2) to specify a private Internet extension for CRLs, freshestCRL. Granted, the freshestCRL CRL extension uses the same OID as a certificate-only extension defined in X.509. But, since the syntax and semantics are the same and they are distinguished by their location (certificate vs. CRL), I don't think this should cause any confusion.

During the earlier discussion, there seemed to be a desire by some to specify whether the pointer to delta-CRLs should be in the certificate or the CRL, and most seemed to prefer to place this information in the CRL. If one is going to do this, then there is the choice between the deltaInfo extension and the freshestCRL extension. One possible advantage of the freshestCRL extension over the deltaInfo extension is that it is more flexible. Of course, this added flexibility may mean additional implementation complexity.

There wasn't really much of a debate in March over whether delta-CRL information should be placed in certificates or CRLs, and if in CRLs whether to use the PKIX freshestCRL extension or the X.509 deltaInfo extension. If you have any thoughts, I'd be interested in hearing them.

Dave

At 12:48 PM 4/11/01 -0700, Covey, Carlin wrote:
>There appears to be a bit of divergence between certain extension names and
>definitions used in X.509 4th Edition X.509_4thEditionDraftV6.pdf and the
>PKIX profile (draft-ietf-pkix-new-part1-05.txt).
>
>draft-ietf-pkix-new-part1-05.txt describes a "Freshest CRL" extension (which
>is also called "Delta CRL Distribution Point").  The extension is described
>in section 4.2.1.16, a subsection under 4.2 Standard Certificate Extensions,
>and it is described again in section 5.2.6, a subsection under 5.2 CRL
>Extensions.  So according to the PKIX profile the extension appears to be
>usable as either a certificate extension or a CRL extension, with identical
>syntax.  Section 8.6.2.6 of X.509 4th edition draft V6 describes a "Freshest
>CRL Extension" with the same syntax as in the PKIX profile, but says it
>shall be used only as a certificate extension.  There is a CRL extension
>defined in X.509 called "Delta Information extension" whose usage appears to
>more or less match the PKIX CRL extension "Freshest CRL," but whose syntax
>is not the same as the X.509 "Freshest CRL" certificate extension.  
>
>Are my document versions out of date, or is this divergence intentional, or
>is it time for a little mid-course correction? 
>
>- Carlin Covey
>   Cylink Corporation

---

From: Sharon Boeyen <[email-masked]>
Date: Wed, 11 Apr 2001 19:33:38 -0400

David, I think this is a problem because X.509 states that the 
freshest CRL extension SHALL only be used as a certificate extension. 
The extension is identified by its OID and any other use of that OID
is non conformant with its definition. X.509 currently has the delta info
extension to point
from a CRL to related delta CRLs. If the syntax of that extension is 
insufficient, then one of the following should happen:
- a new extension is defined that meets the need
- syntax of delta info extension is extended or modified to satisfy the need
- text for freshest CRL extension is modified to allow it to be a
certificate 
as well as a CRL extension.

The 3rd one sounds the simplest and least destructive. Since we are about to
send the current set of 
defects out for final ballot, this is timely. I don't recall specific
discussion 
that drove the freshest CRL to be a certificate only extension, but I think
the text was
basically modelled after CRL DP extension. 

Is there firm agreement in PKIX that this is required? If so, we should
propose 
the change to the 509 list - This could either be done as part of the
current enhancements 
work (similar to the change that will allow subjectDirectoryAttributes to be
set as a critical
extension) or it might be suitable for the defect process.

Cheers,
Sharon
> -----Original Message-----
> From: David A. Cooper [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2001 5:31 PM
> To: [email-masked] '
> Subject: Re: Extension name divergence between PKIX profile and X.509
> 4th Edition
> 
> 
> Carlin,
> 
> This is something that was briefly discussed on the list in 
> early March (see messages with the subject "RE: WG Last Call: 
> Son-of-2459: More about delta-CRLs" in the mail list 
> archive). I don't think there is any problem with what PKIX 
> has done. PKIX has simply chosen (1) not to include the 
> deltaInfo extension in its profile and (2) to specify a 
> private Internet extension for CRLs, freshestCRL. Granted, 
> the freshestCRL CRL extension uses the same OID as a 
> certificate-only extension defined in X.509. But, since the 
> syntax and semantics are the same and they are distinguished 
> by their location (certificate vs. CRL), I don't think this 
> should cause any confusion.
> 
> During the earlier discussion, there seemed to be a desire by 
> some to specify whether the pointer to delta-CRLs should be 
> in the certificate or the CRL, and most seemed to prefer to 
> place this information in the CRL. If one is going to do 
> this, then there is the choice between the deltaInfo 
> extension and the freshestCRL extension. One possible 
> advantage of the freshestCRL extension over the deltaInfo 
> extension is that it is more flexible. Of course, this added 
> flexibility may mean additional implementation complexity.
> 
> There wasn't really much of a debate in March over whether 
> delta-CRL information should be placed in certificates or 
> CRLs, and if in CRLs whether to use the PKIX freshestCRL 
> extension or the X.509 deltaInfo extension. If you have any 
> thoughts, I'd be interested in hearing them.
> 
> Dave
>

---

From: "Covey, Carlin" <[email-masked]>
Date: Wed, 11 Apr 2001 19:37:45 -0700

Sharon and David,

If X.509 is willing to accept "Freshest CRL" as both a
certificate extension and a CRL extension, I prefer that
option.  

- Carlin Covey
  Cylink Corp.

-----Original Message-----
From: Sharon Boeyen
To: 'David A. Cooper'; [email-masked] '
Sent: 4/11/01 4:33 PM
Subject: RE: Extension name divergence between PKIX profile and X.509 4th
Edition

is non conformant with its definition. X.509 currently has the delta
info extension to point 
- syntax of delta info extension is extended or modified to satisfy the
need 

The 3rd one sounds the simplest and least destructive. Since we are
about to send the current set of 
defects out for final ballot, this is timely. I don't recall specific
discussion 
that drove the freshest CRL to be a certificate only extension, but I
think the text was 
basically modelled after CRL DP extension. 

Is there firm agreement in PKIX that this is required? If so, we should
propose 
the change to the 509 list - This could either be done as part of the
current enhancements 
work (similar to the change that will allow subjectDirectoryAttributes
to be set as a critical 
extension) or it might be suitable for the defect process. 

Cheers, 
Sharon 
> From: David A. Cooper [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 Apr 2001 14:26:16 -0400

Sharon:

The inclusion of freshestCRL in either a certificate or CRL has been in
the document for quite some time. I think that it is very attractive for
the "pointer" within a certificate or CRL to have the same
syntax and semantics.

If X.509 can accommodate this approach, I think it would be very
helpful.  I know that at least one implementation is using this
approach.

Russ

At 07:33 PM 4/11/2001 -0400, Sharon Boeyen wrote:

David, I think this is
a problem because X.509 states that the

The extension is identified by its OID and any other use of that
OID

is non conformant with its definition. X.509 currently has
the delta info extension to point

from a CRL to related delta CRLs. If the syntax of that
extension is

- text for freshest CRL extension is modified to allow it to be a certificate

The 3rd one sounds the simplest and least destructive. Since we are about to send the current set of

defects out for final ballot, this is timely. I don't recall specific discussion

that drove the freshest CRL to be a certificate only extension, but I think the text was

Is there firm agreement in PKIX that this is required? If so, we should propose

the change to the 509 list - This could either be done as part of the current enhancements

work (similar to the change that will allow subjectDirectoryAttributes to be set as a critical

Cheers,

Sharon

---

From: Sharon Boeyen <[email-masked]>
Date: Mon, 16 Apr 2001 14:33:45 -0400

I'll raise a defect on the 509 list proposing this. I suspect it won't be
controversial.
 
Sharon

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Friday, April 13, 2001 2:26 PM
To: Sharon Boeyen
Cc: [email-masked]
Subject: RE: Extension name divergence between PKIX profile and X.509 4th
Edition

Sharon:

The inclusion of freshestCRL in either a certificate or CRL has been in the
document for quite some time. I think that it is very attractive for the
"pointer" within a certificate or CRL to have the same syntax and semantics.

If X.509 can accommodate this approach, I think it would be very helpful.  I
know that at least one implementation is using this approach.

Russ

Cheers, 
Sharon

---

From: Peter Williams <[email-masked]>
Date: Mon, 16 Apr 2001 12:10:45 -0700

Sharon
 
Might aswell ensure that the pointer class can be used in any type
of certificate, any type of CRL, and any other type of "security token"
contemplated by X.509.
 
The signed XML work (outside IETF) is completing nicely, with
application to cert management, biometric data, inter-domain messaging 
and authorization. 
 
Signed XML objects can benefit from the generalized standardization of 
references to RevocationLists in X.509.
 
 -----Original Message-----
From: Sharon Boeyen [mailto:[email-masked]]
Sent: Monday, April 16, 2001 11:34 AM
To: 'Russ Housley'; Sharon Boeyen
Cc: [email-masked]
Subject: RE: Extension name divergence between PKIX profile and X.509 4th
Edition

Sharon

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Friday, April 13, 2001 2:26 PM
To: Sharon Boeyen
Cc: [email-masked]
Subject: RE: Extension name divergence between PKIX profile and X.509 4th
Edition

Sharon:

Russ

Cheers, 
Sharon