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

From: Sean Turner <[email-masked]>
Date: Wed, 05 Sep 2012 07:13:34 -0400

Denis,

I think these proposed changes for s4.2 and s4.2.1 are a bit much.

If we need to point out that:

  A CRL MUST NOT include more
  than one instance of a particular extension.

or

  A CRL entry MUST NOT include more
  than one instance of a particular extension.

We could just as easily make those statements in s5.2 and s5.3 as 
opposed to moving text around to have pointers back to the moved text.

Further, folks that aren't in 5280-land can profile really whatever they 
want - and they do.  I don't recall anybody asking for clarifications 
about whether they could include more than one extension in their 
profile of 5280 for a cert/crl/ocsp/etc because of the location of that 
MUST NOT (and it's been there since 2002).

spt

On 8/31/12 6:14 AM, [email-masked] wrote:
> 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 “4.2. Extensions”.
>
> 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.”/
> ////
> 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 OFwhere 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 é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’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
>     “status of any certificate” with “status of the certificate
>     represented by the CRL entry”.
>
>     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.”  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]>
>     [mailto:[email-masked]]
>     <mailto:[mailto:[email-masked]]> *On Behalf Of
>     [email-masked] <mailto:[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 “status of any certificate” with “status of this certificate”
>     b)      Add a new second paragraph in 5.3 that states “/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.”/
>
>     Denis
>
>
>
>     De : Sharon Boeyen <[email-masked]
>     <mailto:[email-masked]>>
>     A : Russ Housley <[email-masked] <mailto:[email-masked]>>
>     Cc : IETF PKIX <[email-masked] <mailto:[email-masked]>>
>     Date : 27/08/2012 19:09
>     Objet : Re: [pkix] Errata in section 5.3 from RFC 5280
>     Envoyé par : [email-masked] <mailto:[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 “status of any certificate” with “status of this certificate”
>     b)      Add a new second paragraph in 5.3 that states “/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 /*/crlExtensions/*/field. 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.”/
>
>     *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 /*/crlExtensions/*/field. 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 the*indirectCRL
>     *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]>[mailto:[email-masked]]
>     <mailto:[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’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’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]>[mailto:[email-masked]]
>     <mailto:[mailto:[email-masked]]>*On Behalf Of *Russ Housley*
>     Sent:* Thursday, August 23, 2012 3:50 PM*
>     To:* [email-masked] <mailto:[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] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/pkix
>
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Sharon Boeyen <[email-masked]>
Date: Wed, 5 Sep 2012 11:23:38 +0000

I am fine with Santosh's proposed modifications:

Cheers,
Sharon

> "status of any certificate" with "status of the certificate

> represented by the CRL entry".

> that advertises a special treatment for it."  In order to use such

---

From: Russ Housley <[email-masked]>
Date: Wed, 5 Sep 2012 09:07:03 -0400

Santosh’s proposed modifications look fine to me
 
-- Russ