Subject: [pkix] Clarifications in section 4.2 from RFC 5280

From: [email-masked]
Date: Mon, 27 Aug 2012 09:02:41 +0200

The discussion about the crlEntryExtensions lead me to read again sections 
4.1.2.9 
and 4.2 from RFC 5280.

Section 4.2 has originally been written only in the context of certificate 
extensions, whereas 
extensions are now used by many other RFCs (in particular RFC 2560, which 
import the Extensions 
syntax and hence its description).

The current text needs to be "clarified". 

I have  reshuffled the text to separate the definition of "extensions", 
used by RFCs 
(including RFC 5280 and RFC 2560) from the definition of  "certificate 
extensions".

Basically, the text which was specific to "certificate extensions" has 
been moved into section 4.2.1.

Section 4.2 which is called "Certificates Extensions" has been renamed 
"Extensions".
It is specific to extensions which are used by any  RFC which wants to use 
the syntax and its meaning.
All the relationships with "certificate extensions" have been removed in 
the new section 4.2.

You will find here after the (1) new proposed text, (2) the current text, 
and (3) an extract from X.509.

NEW PROPOSED TEXT:

4.1.2.9.  Extensions

   This field MUST only appear if the version is 3 (Section 4.1.2.1).
   If present, this field is a SEQUENCE of one or more extensions. 
   The format and content of the extensions field are defined in 
   section 4.2.

4.2.  Extensions

   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
   extnID and the corresponding ASN.1 DER encoded structure is the 
   value of the octet string extnValue.  A SEQUENCE MUST NOT include 
   more than one instance of a particular extension. 

   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.

   A processing system MUST reject the content of the SEQUENCE 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. 

   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).

   In addition, applications conforming to this profile SHOULD recognize
   the authority and subject key identifier (Sections 4.2.1.1 and
   4.2.1.2) and policy mappings (Section 4.2.1.5) extensions.

   This section identifies standard certificate extensions defined in
   [X.509] for use in the Internet PKI. 

 CURRENT  TEXT:

4.1.2.9.  Extensions
   This field MUST only appear if the version is 3 (Section 4.1.2.1).
   If present, this field is a SEQUENCE of one or more certificate
   extensions.  The format and content of certificate extensions in the
   Internet PKI are defined in Section 4.2.

4.2.  Certificate Extensions

   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.  Each extension in a
   certificate is designated as either critical or non-critical.  A
   certificate-using system MUST reject the certificate 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 MAY be ignored if it is not recognized, but MUST be
   processed if it is recognized.  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.

   Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 DER encoded structure is the value
   of the octet string extnValue.  A certificate MUST NOT include more
   than one instance of a particular extension.  For example, a
   certificate may contain only one authority key identifier extension
   (Section 4.2.1.1).  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 CAs conforming to this
   profile.

   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).

   In addition, applications conforming to this profile SHOULD recognize
   the authority and subject key identifier (Sections 4.2.1.1 and
   4.2.1.2) and policy mappings (Section 4.2.1.5) extensions.

4.2.1.  Standard Extensions

   This section identifies standard certificate extensions defined in
   [X.509] for use in the Internet PKI. 

EXTRACT FROM X.509 page 14:

The extensions field allows addition of new fields to the 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. 

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. 

When an implementation processing a certificate does not recognize an 
extension, if the criticality flag is FALSE, 
it may ignore that extension. If the criticality flag is TRUE, 
unrecognized extensions shall cause the structure 
to be considered invalid, i.e., in a certificate, an unrecognized critical 
extension would cause validation of 
a signature using that certificate to fail. 

When a certificate-using implementation recognizes and is able to process 
an extension, then the 
certificate-using implementation shall process the extension regardless of 
the value of the criticality flag. 

Note that any extension that is flagged non-critical will cause 
inconsistent behaviour between certificate-using 
systems that will process the extension and certificate-using systems that 
do not recognize the extension and will ignore it. 

If unknown elements appear within the extension, and the extension is not 
marked critical, those unknown elements 
shall be ignored according to the rules of extensibility documented in 
12.2.2 in ITU-T Rec. X.519 | ISO/IEC 9594-5. 

Denis

---

From: Piyush Jain <[email-masked]>
Date: Mon, 27 Aug 2012 16:44:32 +0000

Denis,

I think your proposal is based on the assumption that existing text in section 4.1.2.9 applies to "type" Extensions as opposed to "instance" of Extensions within structure TBSCertificates.

This assumption may not be correct because in later sections 5280 re- defines what Extensions mean in context of a CRL and in context of CRL entry.
Your proposal would certainly require changes in 5.1.2.7 and 5.2.

Also, your proposed text for Extension imposes restrictions on how other specifications can use this structure.  Please see inline for additional comments
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, August 27, 2012 12:03 AM
To: [email-masked]
Subject: [pkix] Clarifications in section 4.2 from RFC 5280

The discussion about the crlEntryExtensions lead me to read again sections 4.1.2.9
and 4.2 from RFC 5280.

Section 4.2 has originally been written only in the context of certificate extensions, whereas
extensions are now used by many other RFCs (in particular RFC 2560, which import the Extensions
syntax and hence its description).

[piyush] The description in 4.2 applies specifically to extensions in context of tbsCertificates.

I have  reshuffled the text to separate the definition of "extensions", used by RFCs
(including RFC 5280 and RFC 2560) from the definition of  "certificate extensions".

Basically, the text which was specific to "certificate extensions" has been moved into section 4.2.1.

Section 4.2 which is called "Certificates Extensions" has been renamed  "Extensions".
It is specific to extensions which are used by any  RFC which wants to use the syntax and its meaning.
All the relationships with "certificate extensions" have been removed in the new section 4.2.
[piyush] exisiting 4.2 applies  to certificate extension. It does not apply to any other extensions (CRL, Crl Entry or extensions used in 2560, 5055 or any other ARFC). Even within 5280 there are separate sections to define what "Extensions" means in context of CRLs and CRL entries.

You will find here after the (1) new proposed text, (2) the current text, and (3) an extract from X.509.

NEW PROPOSED TEXT:

4.1.2.9.  Extensions

4.2.  Extensions

[piyush] There could be scenarios outside 5280 where more than one instance of same extensions in a sequence are useful.

   A processing system MUST reject the content of the SEQUENCE 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.
[piyush] which SEQUENCE ? immediate parent or the top level SEQUENCE? I think it depends on the extension that is being defined.

[piyush] It is relevant in context of 5280 but other specifications should be free to define their own processing rules.

 CURRENT  TEXT:

4.1.2.9.  Extensions

The extensions field allows addition of new fields to the 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.

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.

When an implementation processing a certificate does not recognize an extension, if the criticality flag is FALSE,
it may ignore that extension. If the criticality flag is TRUE, unrecognized extensions shall cause the structure
to be considered invalid, i.e., in a certificate, an unrecognized critical extension would cause validation of
a signature using that certificate to fail.

When a certificate-using implementation recognizes and is able to process an extension, then the
certificate-using implementation shall process the extension regardless of the value of the criticality flag.

Note that any extension that is flagged non-critical will cause inconsistent behaviour between certificate-using
systems that will process the extension and certificate-using systems that do not recognize the extension and will ignore it.

If unknown elements appear within the extension, and the extension is not marked critical, those unknown elements
shall be ignored according to the rules of extensibility documented in 12.2.2 in ITU-T Rec. X.519 | ISO/IEC 9594-5.

Denis

---

From: Tom Gindin <[email-masked]>
Date: Thu, 30 Aug 2012 08:02:17 -0400

Piyush:

        I can't speak for Denis, but here's what I see.  First, the 
Extension type is typically used in a SEQUENCE OF or SET OF.  Second, the 
critical flag in the Extension always affects the parent of that SEQUENCE 
OF or SET OF, but may not radiate beyond that.  It often goes higher than 
that, but whether it goes to the top of the ASN.1 structure in use depends 
on the particular structure.  For example, invalidating TBSCertificate 
always invalidates Certificate.  At the opposite extreme, a recipient who 
doesn't recognize a critical extension within one of the certificates in 
CMS originatorInfo (see RFC 3852 section 6.1) may still build a chain that 
doesn't include that certificate.
        RFC 5280 section 5.3 says that if "a CRL contains a critical CRL 
entry extension that the application cannot process, then the application 
MUST NOT use that CRL to determine the status of any certificates".  This 
obviously means that an unrecognized critical entry extension invalidates 
tbsCertList and CertificateList, not just the individual entry in 
revokedCertificates.
        Denis' proposal, although I don't believe that it's required as an 
interpretation of the existing standards, boils down to having an 
unrecognized singleExtension invalidate SingleResponse but not 
ResponseData.  The CRL Entry precedent goes against it, since a natural 
rule similar to that precedent would be that "for signed structures 
containing extensions, an unrecognized critical extension renders the 
innermost signature covering the extension invalid".  However, that rule 
is just a generalization of a few cases which we have, rather than a rule 
that has been explicitly adopted by anyone.  I think Denis' proposal is 
better for singleExtension anyway.

Tom Gindin

P.S. - The above opinions are mine, and not necessarily those of my 
employer

From:   Piyush Jain <[email-masked]>
To:     "[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, 
Date:   08/27/2012 12:45 PM
Subject:        Re: [pkix] Clarifications in section 4.2 from RFC 5280
Sent by:        [email-masked]

Denis,
 
I think your proposal is based on the assumption that existing text in 
section 4.1.2.9 applies to ?type? Extensions as opposed to ?instance? of 
Extensions within structure TBSCertificates.
 
This assumption may not be correct because in later sections 5280 re- 
defines what Extensions mean in context of a CRL and in context of CRL 
entry. 
Your proposal would certainly require changes in 5.1.2.7 and 5.2.
 
Also, your proposed text for Extension imposes restrictions on how other 
specifications can use this structure.  Please see inline for additional 
comments
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Monday, August 27, 2012 12:03 AM
To: [email-masked]
Subject: [pkix] Clarifications in section 4.2 from RFC 5280

[piyush] The description in 4.2 applies specifically to extensions in 
context of tbsCertificates.

Section 4.2 which is called "Certificates Extensions" has been renamed 
"Extensions". 
It is specific to extensions which are used by any  RFC which wants to use 
the syntax and its meaning. 
All the relationships with "certificate extensions" have been removed in 
the new section 4.2. 
[piyush] exisiting 4.2 applies  to certificate extension. It does not 
apply to any other extensions (CRL, Crl Entry or extensions used in 2560, 
5055 or any other ARFC). Even within 5280 there are separate sections to 
define what ?Extensions? means in context of CRLs and CRL entries.

NEW PROPOSED TEXT: 

4.1.2.9.  Extensions

4.2.  Extensions 

[piyush] There could be scenarios outside 5280 where more than one 
instance of same extensions in a sequence are useful.

   A processing system MUST reject the content of the SEQUENCE 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. 
[piyush] which SEQUENCE ? immediate parent or the top level SEQUENCE? I 
think it depends on the extension that is being defined. 

[piyush] It is relevant in context of 5280 but other specifications should 
be free to define their own processing rules.

 CURRENT  TEXT: 

4.1.2.9.  Extensions 

Denis 
 _______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix