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

From: [email-masked]
Date: Wed, 22 Aug 2012 18:59:11 +0200

RFC 5280 states on page 69, section 5.3 : CRL Entry Extensions

"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 should be changed into:

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

Denis

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Aug 2012 11:06:18 -0700

On Aug 22, 2012, at 9:59 AM, [email-masked] wrote:

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

This proposed change seems horribly wrong. The change would mean that there is no reason to mark a CRL entry extension as critical or not: the two are the same. Further, you don't use CRL entry extensions to determine the status of the certificate: you use them to determine the nature of the CRL.

Also, it is definitely a proposed change, not an errata.

--Paul Hoffman

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 22 Aug 2012 14:20:09 -0400

I agree with Paul's conclusion, while I would rationalize it more logically.

Specifically, per Section 5.3.3, the certificate issuer not only impacts the entry in which it appears, but subsequent entries.  Thus, adopting Denis's proposal can cause undesirable security issues.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Wednesday, August 22, 2012 2:06 PM
To: [email-masked] PKIX
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280

On Aug 22, 2012, at 9:59 AM, [email-masked] wrote:

> cannot process, then the application MUST NOT use that CRL to 
> determine the status of any certificates".
> 
> cannot process, then the application MUST NOT use that CRL entry to 
> determine the status of this certificate".

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

---

From: [email-masked] (Martin Rex)
Date: Wed, 22 Aug 2012 22:46:13 +0200 (CEST)

>   determine the status of this certificate". 

I'll note that your suggested replacement would create a security problem.

First of all, this semantic has been present in the spec since rfc2459.
Your suggested change would be backwards-incompatible and affect EVERY
PKI implementation that implements CRL processing.  You simply
can not perform such a change to an installed base at this point in time.

So I'm opposing your change.

Curiously, ITU-T X.509 differs from PKIX (rfc2459->rfc5280) on the
semantics when encountering an unrecognized critical CrlEntryExtension:
(relevant parts prefixed with *>)

As you may notice, X.509 does *NOT* specify, that the CRLEntry should
be ignored when accompanied by a critical CRLEntryExtension.  It would
cause a security problem if it did.

Quoting from ITU-T Tec. X.509 (08/2005), Section 7.3, top of page 18:

*>  NOTE 4 -- When an implementation processing a certificate revocation
*>  list does not recognize a critical extension in the crlEntryExtensions
*>  field, it shall assume that, at a minimum, the identified certificate
*>  has been revoked and is no longer valid and perform additional actions
    concerning that revoked certificate as dictated by local policy.
    When an implementation does not recognize a critical extension in the
    crlExtensions field, it shall assume that identified certificates
    have been revoked and are no longer valid. However in the latter case,
    since the list may not be complete, certificates that have not been
    identified as being revoked cannot be assumed to be valid. In this case
    local policy shall dictate the action to be taken. In any case local
    policy may dictate actions in addition to and/or stronger than those
    stated in this Specification.

    NOTE 5 -- 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 that extension shall be indicated as critical in the crlExtensions
    field regardless of where the extension is placed in the CRL.
*>  An extension indicated in the crlEntryExtensions field of an entry shall
*>  be placed in that entry and shall affect only the certificate(s)
*>  specified in that entry.

Although I find the original X.509 semantics for processing
CRLEntryExtensions much more reasonable than what rfc2459->rfc5280 says,
I firmly believe that as IETF we can not retroactively change the
semantics for processing critical CRLEntryExtensions for
rfc2459->rfc5280 & implementations based on these (proposed) standards
(in a backwards-incompatible fashion).

-Martin

---

From: [email-masked]
Date: Thu, 23 Aug 2012 19:25:18 +0200

Martin,

Your email is quite interesting and I was not thinking that the discussion 
on OCSP would lead 
to look at CRLs as defined in  X.509.

Let me first say that RFC  2459 <--> RFC 5280 are supposed to be a 
*profile* of X.509, 
which means dropping some of its complexity, but not changing its 
semantics.

RFC  2459 <--> RFC 5280 are clearly changing the semantics of the 
processing of crlEntryExtensions.

Remainder: do not confuse crlEntryExtensions with crlExtensions.

Let me put together the two paragraphs extracted from X.509 by Martin:

NOTE 5 -- (...)
          An extension indicated in the crlEntryExtensions field of an 
entry shall
          be placed in that entry and shall affect only the certificate(s)
          specified in that entry.

NOTE 4 -- When an implementation processing a certificate revocation
          list does not recognize a critical extension in the 
crlEntryExtensions
          field, it shall assume that, at a minimum, the identified 
certificate
          has been revoked and is no longer valid and perform additional 
actions
          concerning that revoked certificate as dictated by local policy.

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". :

The key question is : which text "makes sense" ?

Using an example, let us see the implications using a CRL with 5000 
entries.

Using the text from X.509, when you look for the revocation status of a 
certificate in a CRL you look 
for the serial number of that certificate. If an entry contains that 
serial number,  then you look also 
at that crlEntryExtensions (you process it) and you are done with a 
result.

Using the text from RFC 5280, when you look for the revocation status of a 
certificate in a CRL, you need 
to look at each of the 5000 entries to see if there is a single 
crlEntryExtension that 
you don't understand and which is marked critical. If one exists, you 
can't determine the revocation status 
of that certificate, even if there is no single critical crlEntryExtension 
 present in the entry which contains 
the serial number of that certificate.

The text from X.509 makes sense, while the text from RFC 5280 does not.

 If we keep the current text from RFC 5280, then RFC 5280 is not 
compatible with X.509.

This is a serious issue.

Many calls for tenders request "X.509 compatibility" and also request RFC 
5280 compatibility for convenience.
How would it be possible to refer to two documents that are incompatible ?

Denis

---

From: "Rich Smith" <[email-masked]>
Date: Thu, 23 Aug 2012 15:32:00 -0400

I agree with Denis 100% and would go a step further and modify his suggested
wording to:

   If a CRL contains a critical CRL entry extension that the application 
  cannot process, then the application MUST NOT use that CRL entry
<+>extension</+> to
  determine the status of this certificate".

If the certificate appears in the CRL it should be treated as revoked,
whether or not the client can process any entry extensions.  That is what is
stated by x.509 as quoted by Martin and I fail to see an instance in which
doing otherwise would make any sense.

-- 

Regards,

Rich Smith

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, August 23, 2012 1:25 PM
To: [email-masked]; [email-masked]
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280

Martin, 

Let me first say that RFC  2459 <--> RFC 5280 are supposed to be a *profile*
of X.509, 
which means dropping some of its complexity, but not changing its semantics.

RFC  2459 <--> RFC 5280 are clearly changing the semantics of the processing
of crlEntryExtensions. 

NOTE 5 -- (...)
         An extension indicated in the crlEntryExtensions field of an entry
shall
         be placed in that entry and shall affect only the certificate(s)
         specified in that entry. 

Using an example, let us see the implications using a CRL with 5000 entries.

Using the text from X.509, when you look for the revocation status of a
certificate in a CRL you look 
for the serial number of that certificate. If an entry contains that serial
number,  then you look also 
at that crlEntryExtensions (you process it) and you are done with a result. 

Using the text from RFC 5280, when you look for the revocation status of a
certificate in a CRL, you need 
to look at each of the 5000 entries to see if there is a single
crlEntryExtension that 
you don't understand and which is marked critical. If one exists, you can't
determine the revocation status 
of that certificate, even if there is no single critical crlEntryExtension
present in the entry which contains 
the serial number of that certificate. 

 If we keep the current text from RFC 5280, then RFC 5280 is not compatible
with X.509. 

This is a serious issue. 

Denis

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Aug 2012 15:50:11 -0400

I agree with the proposal that Denis makes.  I support his proposed text.

>   determine the status of this certificate". : 

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 23 Aug 2012 16:01:16 -0400

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

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 Aug 2012 16:15:12 -0400

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.
>  
> Thus, Denis’s proposal is unacceptable.  If he just wanted to add the sentence as opposed to replace, it would be fine.
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Aug 2012 14:44:03 -0700

>>   determine the status of this certificate". : 

Can you say why? As you said in your later message, only CertificateIssuer can be marked critical. The text for that extension says:
   CRL issuers MUST mark this extension as critical since an
   implementation that ignored this extension could not correctly
   attribute CRL entries to certificates.  This specification RECOMMENDS
   that implementations recognize this extension.
Your support of Denis' text means that you think that reasoning is wrong, and that if an implementation ignored the RECOMMENDS in that last sentence, the implementation then doesn't need to pay attention to the CertificateIssuer at all.

And, yes, I changed the Subject line. This is not an errata: it is a proposed technical change.

--Paul Hoffman

---

From: Piyush Jain <[email-masked]>
Date: Fri, 24 Aug 2012 00:02:05 +0000

Note 5 seems out of context.

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.

Note 4 specifies minimum action but does not impose any constraints on maximum.

Based on above  text from X.509 existing text in 5280 seems incorrect (imposing restrictions unconditionally).

However your proposed text would lead to incorrect behavior if a CRL extension dictates that a CRL entry extension affects more than just the entry in which it is present, a valid scenario according to X.509

-Piyush

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, August 23, 2012 10:25 AM
To: [email-masked]; [email-masked]
Subject: Re: [pkix] Errata in section 5.3 from RFC 5280

Martin,

Your email is quite interesting and I was not thinking that the discussion on OCSP would lead
to look at CRLs as defined in  X.509.

Let me first say that RFC  2459 <--> RFC 5280 are supposed to be a *profile* of X.509,
which means dropping some of its complexity, but not changing its semantics.

RFC  2459 <--> RFC 5280 are clearly changing the semantics of the processing of crlEntryExtensions.

NOTE 5 -- (...)
         An extension indicated in the crlEntryExtensions field of an entry shall
         be placed in that entry and shall affect only the certificate(s)
         specified in that entry.

NOTE 4 -- When an implementation processing a certificate revocation
         list does not recognize a critical extension in the crlEntryExtensions
         field, it shall assume that, at a minimum, the identified certificate
         has been revoked and is no longer valid and perform additional actions
         concerning that revoked certificate as dictated by local policy.

Using the text from X.509, when you look for the revocation status of a certificate in a CRL you look
for the serial number of that certificate. If an entry contains that serial number,  then you look also
at that crlEntryExtensions (you process it) and you are done with a result.

Using the text from RFC 5280, when you look for the revocation status of a certificate in a CRL, you need
to look at each of the 5000 entries to see if there is a single crlEntryExtension that
you don't understand and which is marked critical. If one exists, you can't determine the revocation status
of that certificate, even if there is no single critical crlEntryExtension  present in the entry which contains
the serial number of that certificate.

 If we keep the current text from RFC 5280, then RFC 5280 is not compatible with X.509.

This is a serious issue.

Many calls for tenders request "X.509 compatibility" and also request RFC 5280 compatibility for convenience.
How would it be possible to refer to two documents that are incompatible ?

Denis

---

From: Piyush Jain <[email-masked]>
Date: Fri, 24 Aug 2012 00:07:41 +0000

+1.

And X.509 makes it clear that a CRL extension can be used to indicate if CRL entry extension affects more than just the entry in which it is present.
So Denis's proposal is applicable only in cases where such CRL extensions (e.g idp with indirectCRl set to true) are not present.

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

Russ,

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

Russ

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 23 Aug 2012 20:52:28 -0400

Russ,

If we buy your argument for a minute, whether we change the text or not does not matter based on your assertion below.  To paraphrase what you say below, those who process IDP will process certificate issuer and those who do not process IDP will reject the CRL because of critical CRL extension.  Since it does not matter, status quo is the best course.

As Piyush Jain has pointed out in this thread, if 5280 wants to use X.509 text, we may be able come to some agreement..

My concern is not the extensions listed in 5280.  X.509 V3 is extensible because you can define additional extensions.  The criticality processing/enforcement needs to be robust in light of potential new extensions.  Thus, unless some caveats are added to the scope of an entry extension, this change is unsound.

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

Santosh:

            5.3.1.  Reason Code
            5.3.2.  Invalidity Date

Russ

Russ,

Russ

---

From: [email-masked] (Martin Rex)
Date: Fri, 24 Aug 2012 03:55:40 +0200 (CEST)

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

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.
And X.509 says that the creators of the non-sense ought to include
a critical CRLExtension instead.  this is what the beginning of
Note 5 from X.509 08/2005 section 7.3, page 18 is about:

rfc5280 "enforces" the latter guidance in its own fashion: a critical
crlEntryExtension would have to accompanied by a critical crlExtension
per X.509, and if it is unrecognized, then the whole CRL must be rejected
as if this has been an unrecognized critical crlExtension (which per
X.509 should have been there in the first place).

For an implementation, however the rfc5280 description is much harder
to implement.  It is not unusal that the ASN.1 parser and the
code that processes the objects (e.g. CRL checking) are seperate
and independently maintaind.  Potentially, the ASN.1 parser could
even be compiler-generated, so that it could happen that a
crlEntryExtension is not "unrecognized" for the ASN.1 Parser,
but unrecognized for the code that performs CRL acutal checking.

The rfc5280 definition implies, that in such a case the CRL checking
code must scan the entire CRL (all entries) in order to ensure that
there are no critical unrecognized crlEntryExtensions.

-Martin

---

From: Piyush Jain <[email-masked]>
Date: Fri, 24 Aug 2012 03:24:56 +0000

Please see inline.

> Martin Rex
> Sent: Thursday, August 23, 2012 6:56 PM
> To: Santosh Chokhani
> Cc: IETF PKIX
> "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?

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

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

this is what the beginning of Note 5 from X.509
> 08/2005 section 7.3, page 18 is about:
> 
> crlEntryExtension would have to accompanied by a critical crlExtension per
> X.509, and if it is unrecognized, then the whole CRL must be rejected as if this
> has been an unrecognized critical crlExtension (which per

Agreed. I think that carrying over X.509 text to 5280 is the right approach to address this.

> 
> For an implementation, however the rfc5280 description is much harder to
> implement.  It is not unusal that the ASN.1 parser and the code that
> processes the objects (e.g. CRL checking) are seperate and independently
> maintaind.  Potentially, the ASN.1 parser could even be compiler-generated,
> so that it could happen that a crlEntryExtension is not "unrecognized" for the
> ASN.1 Parser, but unrecognized for the code that performs CRL acutal
> checking.
> 
> The rfc5280 definition implies, that in such a case the CRL checking code must
> scan the entire CRL (all entries) in order to ensure that there are no critical
> unrecognized crlEntryExtensions.
> 

Agreed.  The text needs to be changed.

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 24 Aug 2012 20:01:28 +0200

Bonsoir,

> which means dropping some of its complexity, but not changing its semantics.

The semantics has already been changed regarding trust anchor and validation.

CRL Processing (6.3.3) step (f) is incompatible with §8.1.5 of X.509
on self-issued certificates, for example.

Trust anchor renewal as processed by RFC5280 is a problem on current
CSCA deployments.

-- 
Erwann.

---

From: Sharon Boeyen <[email-masked]>
Date: Mon, 27 Aug 2012 16:39:10 +0000

Russ, I realize the RFC 5280 references the 2005 edition of X.509. However the 2009 edition (freely available at http://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

Santosh:

            5.3.1.  Reason Code
            5.3.2.  Invalidity Date

Russ

Russ,

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Aug 2012 12:42:24 -0400

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

---

From: Sharon Boeyen <[email-masked]>
Date: Mon, 27 Aug 2012 17:08:48 +0000

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

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:

Russ

Cheers,
Sharon

Santosh:

            5.3.1.  Reason Code
            5.3.2.  Invalidity Date

Russ

Russ,

Russ

---

From: [email-masked]
Date: Mon, 27 Aug 2012 19:19:44 +0200

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]>
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é par :    [email-masked]

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

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

Russ, I realize the RFC 5280 references the 2005 edition of X.509. However 
the 2009 edition (freely available at
http://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

Russ Housley
 
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
 
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:

To my mind, the support for the critical IssuingDistributionPoint CRL 
extension includes the proper support for the Certificate Issuer CRL entry 
extension.
 
Russ

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.
 
Russ Housley

 
Russ

---

From: Sean Turner <[email-masked]>
Date: Tue, 28 Aug 2012 11:33:45 -0400

Denis,

PKIX supports the 1st part (partitioned & delta CRLs) of the eg but not 
the 2nd part (CRL scope extension) so we could we just remove the ", or 
an entry may represent a range of certificates" from the parenthetical?

spt

On 8/27/12 1:19 PM, [email-masked] wrote:
> 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
> is a related critical extension in the *crlExtensions*//field
> that advertises a special treatment for it.”/
>
> Denis
>
>
>
> ------------------------------------------------------------------------
>
>
>
> 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:
>
> Russ, I realize the RFC 5280 references the 2005 edition of X.509.
> However the 2009 edition (freely available
> at_http://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
> /*/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/*/./
>
>
> 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:
>
>
> 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:
>
> extension includes the proper support for the Certificate Issuer CRL
> entry extension.
>
> Russ
>
>
> 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
>
>

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 28 Aug 2012 13:45:14 -0400

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]] 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,

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]>
________________________________

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

Sharon:

Russ

Cheers,
Sharon

Santosh:

            5.3.1.  Reason Code
            5.3.2.  Invalidity Date

Russ

Russ,

Russ

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

---

From: Piyush Jain <[email-masked]>
Date: Thu, 30 Aug 2012 15:39:01 +0000

+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,

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,

Denis

Sharon:

Russ

Cheers,
Sharon

Santosh:

            5.3.1.  Reason Code
            5.3.2.  Invalidity Date

Russ

Russ,

Russ