Subject: Re: [pkix] Errata in section 5.3 from RFC 5280

From: [email-masked]
Date: Fri, 31 Aug 2012 12:14:09 +0200

Piyush,
 
I read your arguments. However, when an ASN.1 parameter is defined in an RFC
and when it is imported by another RFC, both the ASN.1 syntax *and its semantics* 
are imported.
 
RC 5280 omitted to define the semantics of Extensions independently of the context of 
certificates and CRLs, hence why such a definition is needed, since Extensions is 
imported and used in other RFCs, including OCSP.
 
So you are correct: changes are also required in sections 5.1.2.7 and 5.2, so that 
they can refer to the new proposed section &#8220;4.2. Extensions&#8221;.
 
I believe that the following argument you raised is valid:
 
   A SEQUENCE MUST NOT include more than one instance of a 
   particular extension. 
There could be scenarios outside 5280 where more than one instance of same 
extensions in a sequence are useful.
 
So this sentence should be removed from the proposed new section 4.2 and moved 
to section 4.2.1.
 
Section 4.2 has been redrafted to include the case indicated by Sharon which is:
 
Therefore, a critical extension in the crlEntryExtensions field of an entry shall affect 
only the certificate specified in that entry, unless there is a related critical extension 
in the crlExtensions field that advertises a special treatment for it.&#8221;

However, this text has been generalized since it is applicable in general and not only to crlEntryExtensions.
 
Here is a new proposed text for sections 4.2 and 4.2.1:
 
   The extensions field allows addition of new fields to a structure 
   without modification to the ASN.1 definition.  An extension field 
   consists of an extension identifier, a criticality flag, and an 
   encoding of a data value of an ASN.1 type associated with the 
   identified extension. 

   Each extension includes an OID and an ASN.1 structure.  When an 
   extension appears in a structure, the OID appears as the field e
   extnID and the corresponding ASN.1 DER encoded structure is the 
   value of the octet string extnValue.  
 
   For those extensions where ordering of individual extensions within 
   the SEQUENCE is significant, the specification of those individual 
   extensions shall include the rules for the significance of the order 
   therein. 

   An extension includes the boolean critical, with a default value of 
   FALSE.  The text for each extension specifies the acceptable values 
   for the critical field for implementations conforming to this 
   profile. 

   An extension marked critical in a field from a SEQUENCE or 
   from a SET OF shall only affect that SEQUENCE or that SET OF, 
   unless there is another critical extension in an upper SEQUENCE or 
   an upper SET OF which advertises a special treatment for it.  In 
   such a case, the relying party must be able to process both critical 
  extensions.
 
   A processing system MUST reject the content of the SEQUENCE or  
   of the SET OF where the extension appears if it encounters a critical 
   extension it does not recognize or a critical extension that contains 
   information that it cannot process. 
 
   A non-critical extension MUST be processed if it is recognized and 
  MAY be ignored if it is not recognized. 
   Note that any extension that is flagged non-critical will cause 
   inconsistent behaviour between processing systems that will process 
   the extension and processing systems that do not recognize the 
   extension and will ignore it. 
 
4.2.1.  Standard Extensions 

 The following sections present recommended extensions used within 
  Internet certificates and standard locations for information.   

 Communities may elect to use additional extensions; however, 
  caution ought to be exercised in adopting any critical extensions 
  in certificates that might prevent use in a general context. 

 The extensions defined for X.509 v3 certificates provide methods for 
 associating additional attributes with users or public keys and for 
 managing relationships between CAs.  The X.509 v3 certificate format 
 also allows communities to define private extensions to carry 
  information unique to those communities.
 
   A certificate NOT include more than one instance of a particular 
   extension.    

  Conforming CAs MUST support key identifiers (Sections 4.2.1.1 and 
  4.2.1.2), basic constraints (Section 4.2.1.9), key usage (Section 
  4.2.1.3), and certificate policies (Section 4.2.1.4) extensions.  If 
  the CA issues certificates with an empty sequence for the subject   
    field, the CA MUST support the subject alternative name extension 
  (Section 4.2.1.6).  Support for the remaining extensions is OPTIONAL. 
  Conforming CAs MAY support extensions that are not identified within 
  this specification; certificate issuers are cautioned that marking 
  such extensions as critical may inhibit interoperability. 

   At a minimum, applications conforming to this profile MUST recognize 
   the following extensions: key usage (Section 4.2.1.3), certificate 
   policies (Section 4.2.1.4), subject alternative name (Section 
   4.2.1.6), basic constraints (Section 4.2.1.9), name constraints 
   (Section 4.2.1.10), policy constraints (Section 4.2.1.11), extended 
   key usage (Section 4.2.1.12), and inhibit anyPolicy (Section 
   4.2.1.14).

Here is a new proposed text for sections 5.1.2.7 and 5.2:

5.1.2.7.  Extensions 
   This field may only appear if the version is 2 (Section 5.1.2.1).  If
   present, this field is a sequence of one or more CRL extensions.  CRL
   extensions are discussed in Section 5.2.
5.2.  CRL Extensions
   The extensions field defined in section 4.2 provide a method for associating
   additional attributes with CRLs.  The v2 CRL format also allows
   communities to define private extensions to carry information unique
   to those communities.  Each extension in a CRL may be designated as 
   critical or non-critical. If a CRL contains a critical CRL extension 
   that the application cannot process, then the application MUST NOT 
   use that CRL to determine the status of any certificate identified 
   in that entry.  However, applications may ignore unrecognized non-
   critical CRL extensions.
Here is a new proposed text for sections 5.3:
5.3.  CRL Entry Extensions
   The extensions field defined in section 4.2 provide a method for associating
   additional attributes with CRL entries.  The v2 CRL format also 
   allows communities to define private CRL entry extensions to carry
   information unique to those communities.  Each extension in a CRL
   entry may be designated as critical or non-critical.  If a CRL
   contains a critical CRL entry extension that the application cannot
   process, then the application MUST NOT use that CRL entry to 
   determine the status of the certificate identified in that entry.
   
   The following subsections present recommended extensions used within
   Internet CRL entries and standard locations for information.
   Communities may elect to use additional CRL entry extensions;
   however, caution should be exercised in adopting any critical CRL
   entry extensions in CRLs that might be used in a general context.
   Support for the CRL entry extensions defined in this specification is
   optional for conforming CRL issuers and applications.  However, CRL
   issuers SHOULD include reason codes (Section 5.3.1) and invalidity
   dates (Section 5.3.2) whenever this information is available.
Denis

-----Piyush Jain <[email-masked]> a &#8218;crit : ----- 
A : Santosh Chokhani <[email-masked]>, "[email-masked]" <[email-masked]>, Sharon Boeyen <[email-masked]>
De : Piyush Jain <[email-masked]>
Date : 30/08/2012 17:39
Cc : IETF PKIX <[email-masked]>
Objet : RE: [pkix] Errata in section 5.3 from RFC 5280

+1
 
Addresses the case where a RP understands IDP but does not understand CRLIssuers.
Santosh&#8217;s proposal calls it out explicitly making it clearer.
From: [email-masked] [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Tuesday, August 28, 2012 10:45 AM
To: [email-masked]; Sharon Boeyen
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280
 
Denis and Sharon,
 
I would propose the following:
 
a)      In the penultimate sentence of the first paragraph of 5.3 replace &#8220;status of any certificate&#8221; with &#8220;status of the certificate represented by the CRL entry&#8221;.
 
b)      A critical extension in the crlEntryExtensions field of an entry shall affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it.&#8221;  In order to use such CRL, the relying party must be able to process both the crlEntryExtension and the related crlExtension. 
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 27, 2012 1:20 PM
To: Sharon Boeyen
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280
 
Sharon, 

Thank you for the proposal. 

I believe that a simplification would be possible, since we do not describe all the features of  X.509 in RFC 5280: 

a)      In the penultimate sentence of the first paragraph of 5.3 replace &#8220;status of any certificate&#8221; with &#8220;status of this certificate&#8221; 
b)      Add a new second paragraph in 5.3 that states &#8220;Therefore, a critical extension in the crlEntryExtensions field of an entry
shall affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field 
that advertises a special treatment for it.&#8221; 

Denis 

De :        Sharon Boeyen <[email-masked]> 
A :        Russ Housley <[email-masked]> 
Cc :        IETF PKIX <[email-masked]> 
Date :        27/08/2012 19:09 
Objet :        Re: [pkix] Errata in section 5.3 from RFC 5280 
Envoy&#8218; par :        [email-masked] 

I think the easiest way to clarify it would be: 
  
a)      In the penultimate sentence of the first paragraph of 5.3 replace &#8220;status of any certificate&#8221; with &#8220;status of this certificate&#8221; 
b)      Add a new second paragraph in 5.3 that states &#8220;If an extension affects the treatment of the list (e.g., multiple CRLs need to be scanned to examine the entire list of revoked certificates, or an entry may represent a range of certificates), then either that extension or a related extension shall be indicated as critical in the crlExtensionsfield. Therefore, a critical extension in the crlEntryExtensions field of an entry shall affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it.&#8221; 
  
From: Russ Housley [mailto:[email-masked]] 
Sent: Monday, August 27, 2012 12:42 PM
To: Sharon Boeyen
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 
  
Sharon: 
  
Thanks for digging up those words.  They support the position that I have stated. 
  
How do you believe the clarifications document should change to express this point? 
  
Russ 

On Aug 27, 2012, at 12:39 PM, Sharon Boeyen wrote: 

Russ, I realize the RFC 5280 references the 2005 edition of X.509. However the 2009 edition (freely available athttp://www.x500standard.com/index.php?n=Ig.LatestAvail ) revises this text again slightly and I think makes the intent even clearer. It states (as part of the main text and no longer a note): 
  
If an extension affects the treatment of the list (e.g., multiple CRLs need to be scanned to examine the entire list of revoked certificates, or an entry may represent a range of certificates), then either that extension or a related extension shall be indicated as critical in the crlExtensionsfield. Therefore, a critical extension in the crlEntryExtensions field of an entry shall affect only the certificate specified in that entry, unless there is a related critical extension in the crlExtensions field that advertises a special treatment for it. The only example of this situation defined in this Specification is the certificateIssuer CRL entry extension and the related issuingDistributionPoint CRL extension when theindirectCRL Boolean from that extension is set to TRUE. 

This is clearly the case for certificateIssuer as you indicate below and as you note below the only other 2 standard crl entry extensions are irrelevant as they can only ever be non-critical and affect only the single identified revoked certificate. Any private extension that might be defined as a crlEntry extension would also have to follow that same rule to be compliant with the base standard. I do believe the 2005 text was clear but offer this 2009 as additional confirmation of the intent (I personally find this text even clearer). 
  
Cheers, 
Sharon 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, August 23, 2012 4:15 PM
To: Santosh Chokhani
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 
  
Santosh: 

RFC 5280 describes three CRL Entry Extensions, and all of them come from X.509: 
  
            5.3.1.  Reason Code 
            5.3.2.  Invalidity Date 
            5.3.3.  Certificate Issuer 
  
The first two do not have the concern that you describe, and the third one should only be present if the CRL includes the IssuingDistributionPoint CRL extension, and that extension includes the indirectCRL set to TRUE.  The IssuingDistributionPoint CRL extension must be critical.  RFC 5280 says: 
  
   The issuing distribution point is a critical CRL extension that 
   identifies the CRL distribution point and scope for a particular CRL, 
   and it indicates whether the CRL covers revocation for end entity 
   certificates only, CA certificates only, attribute certificates only, 
   or a limited set of reason codes.  Although the extension is 
   critical, conforming implementations are not required to support this 
   extension.  However, implementations that do not support this 
   extension MUST either treat the status of any certificate not listed 
   on this CRL as unknown or locate another CRL that does not contain 
   any unrecognized critical extensions. 
  
To my mind, the support for the critical IssuingDistributionPoint CRL extension includes the proper support for the Certificate Issuer CRL entry extension. 
  
Russ 

On Aug 23, 2012, at 4:01 PM, Santosh Chokhani wrote: 

Russ, 
  
The problem with Denis&#8217;s proposal is that he wants to replace the text of not using the CRL. 
  
I have cited a specific example in 5280 itself where an entry extension scope goes beyond that of the entry.  It potentially impacts subsequent entries. 
  
Thus, Denis&#8217;s proposal is unacceptable.  If he just wanted to add the sentence as opposed to replace, it would be fine. 
  
In general, unless 5280 and X.509 stated that an entry extension cannot impact semantics of anything in the CRL other than the entry itself, what you say is unacceptable and potentially insecure. 
  
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Thursday, August 23, 2012 3:50 PM
To: [email-masked]
Cc: IETF PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280 

I agree with the proposal that Denis makes.  I support his proposed text. 
  
This validates my text proposal which still is: 

  If a CRL contains a critical CRL entry extension that the application 
 cannot process, then the application MUST NOT use that CRL entry to
 determine the status of this certificate". : 
  
Russ 
  
 _______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix