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

From: [email-masked] (Martin Rex)
Date: Thu, 20 Sep 2012 05:19:28 +0200 (CEST)

(still catching up on pre-vacation Email...)

Piyush Jain wrote:
>
> Martin Rex wrote:
> > 
> > The real problem is this:
> > 
> > A critical crlEntryExtension is IMHO semantical non-sense, saying:
> > "A certificate is revoked, but only under the following constraints
> >  -- and if you don't understand this, consider the certificate valid".
>
> Not sure if I understand the basis for this interpretation.
> Did you type "valid" instead of "unknown" accidentally?

I really meant "valid" here (although you're correct that I occasionally
have typos of such a kind in my replies).

But this interpretation is limited/scoped to the semantics originally
favoured by Denis, that a crlEntryExtension ought to affect only the
validity of the crlEntry where this crlEntryExtension appears, even
when it is marked critical and unrecognized, but not affect the
validity of the entire CRL.

> 
> > The guidance in X.509 is, that the criticality is to be ignored and
> > the cert to which the CrlEntry refers must be considered revoked.
> 
> Only in some situations.

Putting the "local policy" aside, NO, the X.509 guidance is absolute,
for certs that _appear_ on the CRL.

However, X.509 the NOTE 4 & 5 semantics fail to account for the ReasonCode
removeFromCRL, and it also fail to account for the issuerName compression
scheme for indirectCRLs.   Which effectively kills these protocol features,
because the behaviour of conforming implementations is unpredictable.

> 
> > And X.509 says that the creators of the non-sense ought to include a
> > critical CRLExtension instead.  
>
> Indirect CRLs are defined in X.509. So I doubt that the authors of X.509
> considered it nonsense. In hindsight, based on adoption of indirect CRLs,
> you can probably say that indirectCRLs are not useful but "nonsense"
> is little strong.

I was using "nonsense" or "non-sensical" as a colloquial substitute
for "logical fallacy".

I don't know the exact history of indirectCRLs throughout X.509, but
the X.509 08/2005 contains serious logical fallacies (contradictions)
in its definition.

(incomplete) list of X.509 specifies about indirect CRLs:

 (1)  8.6.2.2 Issuing distribution point extension (crlExtension)
      (1a) contains a boolean "indirectCRL"
      (1b) requires this crlExtension to be always critical

 (2)  8.6.2.3 Certificate issuer extension (crlEntryExtension)
      (2a) requires the (always critical) issuingDistributionPoint
           crlExtension to be present and its indirectCRL boolean
           to be asserted/TRUE
      (2b) defines a non-obvious issuer name compression scheme
           where a critical crlEntryExtension substantially changes the
           meaning of all crlEntries following it, though none of the
           affected later crlEntries will contain such a critical
           crlEntryExtension.
      (2c) requires this crlEntryExtension to be always critical,
           rationalizing that if an implemenation ignored this extension,
           it would not correctly attribute CRL entries to certificates

 (3)  7.3 Certificate Validity
      (3a) defines the general processing rules for CRLs 
      (3b) specifies in NOTE 4 (first sentence) that when encountering
           an unrecognized critical crlEntryExtension, it shall assume that
           the cert identified by the crlEntry has been revoked
      (3c) specifies in NOTE 4 (second sentence) that when encountering
           an unrecognized critical crlExtension, it shall assume that
           all certs identified by crlEntries on that CRL are revoked
      (3d) specifies in NOTE 5 (first sentence) that when an extension
           affects the treatment of the list, that the extension shall
           be indicated as critical in the crlExtensions field regardless
           of where the extension is.
      (3e) specifies in NOTE 5 (second sentence) that a crlEntryExtension
           shall affect only the certificate(s) specified in that crlEntry

Problems in the above:
- (2c) rationale is lame because (2b) specifies that it changes
       semantics of (later) crlEntries without appearing as critical
       crlEntryExtension in those later crlEntries.
- (3c) contradicts and completely invalidates the rationale of (2c). 
- (3d) is in conflict with (2c), because the critical Certificate issuer
       extension is not replicated as a critical crlExtension
          However, a spec weasel might argue that an indirectCRL requires
       a critical issuingDistributionPoint crlExtension with indirectCRL=TRUE
       to be present, which could be seen as functionally sufficient.
          The latter suggest that the rationale (2c) should have really
       refered to the presence of the critical crlExtension Issuing
       Distribution point carrying the indirectCRL=TRUE boolean,
       indicating that the semantics of much more crlEntries might be affected
       besides those few that contain a critical crlEntryExtension.
- (3c)+(3b) entirely kill the safeguarding of the (2b) compression scheme,
       neither the existing (2c) rationale, nor the more preferable
       "critical issuing distribution point presence" are compatible with (3c)

Btw. I just noticed what looks like an(other) inconsistency in rfc5280 to me,
about the processing of an unrecognized critical crlExtension.  Curiously
the statement in 5.2.5 is consistent with X.509's problematic (3c) above.

  http://tools.ietf.org/html/rfc5280#section-5.2.5

     5.2.5. Issuing Distribution Point

     [...]                              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.

  http://tools.ietf.org/html/rfc5280#section-5.2

     5.2. CRL Extensions

     [...]                       If a CRL contains a critical extension
     that the application cannot process, then the application MUST NOT
     use that CRL to determine the status of certificates.

The scoping in the sentence above (*>) "treat the status of any certificate
not listed on this CRL as unknown" suggests that this CRL can be legitimately
used to determine the status of certificate that _are_listed_ on this CRL.

The statement in 5.2.5 is particularly concerning when changing rfc5280
(e.g. clarifications-09) to allow use of CRLs with unrecognized critical
crlEntryExtensions to determine status of certs by ignoring only the
crlEntries with such crlEntryExtensions.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 20 Sep 2012 07:36:26 +0200 (CEST)

Following up to myself.

I just noticed Sharon Boeyen's response here:
http://www.ietf.org/mail-archive/web/pkix/current/msg31651.html

that indicates the discussed problematic NOTE 4&5  X.509 2005/08 issues
were fixed in the X.509 2008/11 revision.

  X.509 11/2008, Section 7.3 Certificate Validity, top of page 19:

  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 Directory
  Specification is the certificateIssuer CRL entry extension and the
  related issuingDistributionPoint CRL extension when the indirectCRL
  Boolean from that extension is set to TRUE.

The above changes fixes two serious problems
(NOTE 4, second sentence) about assuming a cert _listed_ on the CRL being
revoked even when an unrecognized critical crlExtension is present,
and (NOTE 5, second sentence) "an extension placed in the crlEntryExtension
of an entry shall affect only the certificate(s) specified in that entry"
direct conflict with the issuer name compression scheme used in indirectCRL
because that affects later crlEntries, not just the crlEntry that contains
the certificateIssuer crlEntryExtension.

The other change, not explicitly quoted in Sharon's Mail:

   Quoting from X.509 11/2008, section 7.3, bottom of page 18:

   When an implementation processing a CRL encounters the serial number
   of the certificate of interest in a CRL entry, but does not recognize
   a critical extension in the crlEntryExtensions field from that CRL
   entry, that CRL cannot be used to determine the status of the certificate.

fixes the ambiguity created by (NOTE4, first sentence) about assuming the
cert to be revoked and invalid and a possible  removeFromCRL ReasonCode
and it avoids missing an actual revocation that happens to come along
with an unrecognized critical crlEntryExtension but no critical crlExtension
saying "you will need to get a better CRL for this particular cert" 
--which is preferabel to the unsafe clarifications-09 approach to blindly
ignore a crlEntry that carries an unrecognized critical crlEntryExtension
(...provided that the RP _can_ find a better CRL and does not soft-fail).

-Martin

---

From: "Jon Doyle (AzureCoast)" <[email-masked]>
Date: Thu, 20 Sep 2012 08:02:40 +0200

On Sep 20, 2012, at 7:36 AM, [email-masked] (Martin Rex) wrote:

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

Jon Doyle
Director of Corporate Strategy
AzureCoast LLC
+33 626 59 66 27

Cloud Communication Technology and Services that fly

Join us in the community:

LinkedIN: "AzureCoast"

---

From: Piyush Jain <[email-masked]>
Date: Thu, 20 Sep 2012 16:25:04 +0000

Martin,

I do believe that the inconsistency you caught (listed toward the end of your message) is a genuine one and should be fixed in any updates to RFC 5280.

To summarize - 
Section 5.2.5 on IDP implies that even if IDP extension is not supported, implementations can treat the certificates in the CRL as revoked whereas section 5.2 states that CRL s with unrecognized critical extension MUST not be used to determine the status of any certificates.

The existing text in 5.2.5 is 
"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"

It should be replaced by
"However, implementations that do not support this extension MUST not use this CRL to determine the status of any certificate."

-Piyush

---

From: [email-masked]
Date: Mon, 24 Sep 2012 08:12:39 +0200

We now need to move forward and discuss text changes. 
Here after is a strawman proposal to fix the issue:

TEXT CURRENTLY IN DRAFT -09:

|     The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9
|     for X.509 v2 CRLs provide methods for associating additional 
|     attributes with CRL entries [X.509] [X9.55].  The X.509 v2 CRL 
|     format also allows communities to define private CRL entry 
|     extensions to carry information unique to those communities. 
|     Each extension in a CRLentry 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 to determine the status of the certificate 
|     represented by the CRL entry.  However, applications may ignore
|     unrecognized non-critical CRL entry extensions.

   A new second paragraph is added to RFC 5280, Section 5.3 that states:

|     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
|     a CRL, the relying party MUST be able to process both the
|     crlEntryExtension and the related crlExtension.

NEW PROPOSED TEXT:

|     The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9
|     for X.509 v2 CRLs provide methods for associating additional 
|     attributes with CRL entries [X.509] [X9.55].  The X.509 v2 CRL 
|     format also allows communities to define private CRL entry 
|     extensions to carry information unique to those communities. 
|     Each extension in a CRLentry may be designated as critical or 
|     non-critical. 
|
|     If a CRL contains a non critical CRL entry extension that an 
|     application cannot process, and if there is no related critical 
|     extension in the crlExtensions field which mandates its 
|     processing, then the application may ignore the unrecognized 
|     non-critical CRL entry extension.
|
|     If a CRL contains a critical CRL entry extension that an 
|     application cannot process, unless there is a related critical 
|     extension in the crlExtensions field which specifies a specific 
|     treatment for it, then the status of certificate identified by 
|     the CRL entry shall be considered as unkown.

Denis

Note: if this text proposal does not fully solve the issue, please provide 
an alternative text 
        (in addition to a short rational) so that we can move forward.

---

From: [email-masked] (Martin Rex)
Date: Mon, 24 Sep 2012 16:11:25 +0200 (CEST)

> |     unrecognized non-critical CRL entry extensions.

The idea behind the changed sentence is correct in principle:

                     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 the certificate 
     represented by the CRL entry.

but the wording is incorrect.  X.509 11/2008 is better:

    When an implementation processing a CRL encounters the serial number
    of the certificate of interest in a CRL entry, but does not recognize
    a critical extension in the crlEntryExtensions field from that CRL
    entry, that CRL cannot be used to determine the status of the
    certificate.

"certificate represented by the CRL entry" is wrong, because for
a crlEntry with an unrecognized critical issuer name crlEntryExtension,
the relevant point is not which certificate the crlEntry represents
(which is serial PLUS explicit issuer name), but instead what information
of the crlEntry the application matches (the serial number alone) when it
does not recognize the critical issuer name crlEntryExtension.

> |     crlEntryExtension and the related crlExtension.

The paragraph that was newly added to -09 is confusing, because it sounds
like it is relevant for RPs, but actually the first sentences is relevant
for designers for crlEntryExtensions instead and the second sentence is
confusing.

The relevant & correct sentence for RPs from X.509 11/2008:

    When an implementation does not recognize a critical extension in the
    crlExtensions field, that CRL cannot be used to determine the status
    of the certificate, regardless of whether the serial number of the
    certificate of interest appears in that CRL or not.

-Martin