Subject: [pkix] 5280bis, v-09

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Sep 2012 12:22:35 -0400

OK, here we go again!

Peter posted the -09 version late last week, and my intent is to conduct 
a constrained WGLC
on the new text, dealing with CRL entry extensions. Denis beat me to the 
punch!

So, the WGLC started on Friday (9/7), and ends on 9/17.

As for Denis's comments:

1- yes, the intro needs to be changed to reflect the new section. Peter, 
please plan to do
this for v-10, to be issued after WGLC.

2- I'm comfortable with the current text here, but if Peter want's to 
change to "identified"
I have no problem with that, in v-10.

3- I'm not going to require the change you suggest here. It's too 
extensive at this point.

Steve

---

From: "Peter Yee" <[email-masked]>
Date: Tue, 11 Sep 2012 00:51:29 -0700

I'll have -10 ready with the updated intro and I'm happy to switch to
"identified in".  

			-Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Monday, September 10, 2012 9:23 AM
To: pkix
Subject: [pkix] 5280bis, v-09

OK, here we go again!

Peter posted the -09 version late last week, and my intent is to conduct a
constrained WGLC on the new text, dealing with CRL entry extensions. Denis
beat me to the punch!

As for Denis's comments:

1- yes, the intro needs to be changed to reflect the new section. Peter,
please plan to do this for v-10, to be issued after WGLC.

2- I'm comfortable with the current text here, but if Peter want's to change
to "identified"
I have no problem with that, in v-10.

3- I'm not going to require the change you suggest here. It's too extensive
at this point.

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

---

From: [email-masked] (Martin Rex)
Date: Thu, 13 Sep 2012 02:24:44 +0200 (CEST)

I'm for long silence, I was on vacation (only told Denis about it).

Stephen Kent wrote:
> a constrained WGLC on the new text, dealing with CRL entry extensions.
> Denis beat me to the punch!
> 

I object to the proposed new text about CRLEntryExtensions
in the clarification document, because as is, would significantly
worsen the difference between PKIX and X.509 and make things
clearly incompatible rather than slightly less efficient.

If anything, the gap should be reduced, compatibility between
PKIX and X.509 improved and the original architecture not violated.

Please recall the original NOTE 4 & 5 that I quoted from
ITU-T Rec. X.509 (08/2005), Section 7.3, top of page 18:
(get them here http://www.itu.int/rec/T-REC-X.509):

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

b>  When an implementation does not recognize a critical extension in the
b>  crlExtensions field, it shall assume that identified certificates
b>  have been revoked and are no longer valid.

c>                                             However in the latter case,
c>  since the list may not be complete, certificates that have not been
c>  identified as being revoked cannot be assumed to be valid. In this case
c>  local policy shall dictate the action to be taken. In any case local
c>  policy may dictate actions in addition to and/or stronger than those
c>  stated in this Specification.

d>  NOTE 5 -- If an extension affects the treatment of the list
d>  (e.g., multiple CRLs need to be scanned to examine the entire list of
d>  revoked certificates, or an entry may represent a range of certificates),
d>  then that extension shall be indicated as critical in the crlExtensions
d>  field regardless of where the extension is placed in the CRL.

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

(I inserted blank lines above for visual clarity of the X.509 requirements).

two options, all combinations:

 (1) cert     on CRL, CRL with NO unrecognized critical CRLEntryExtensions 
 (2) cert NOT on CRL, CRL with NO unrecognized critical CRLEntryExtensions 
 (3) cert     on CRL, CRL with    unrecognized critical CRLEntryExtension
 (4) cert NOT on CRL, CRL with    unrecognized critical CRLEntryExtension

I hope we agree that X.509 and rfc5280 agree on (1) and (2) results
for CRL checking.

rfc5280 currently says that for (3)+(4) the entire CRL ought to be ignored
and other CRLs need to be evaluated "UNDETERMINED"

X.509 says in (a>) that for (3) the status of the cert is definitely revoked
and says in (c>) for (4) that the CRL ought to be ignored and other CRLs need
to be evaluated "UNDETERMINED"

While both X.509 and rfc5280 agree on the result for (4) "UNDETERMINED",
there is the superficial appearance of a difference for a casual
implementer for case (3) between X.509 "REVOKED" and rfc5280 "UNDETERMINED"
that might lead to a slightly less efficient processing CRLs.

The newly proposed text (in -09):

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

creates a significantly distinct behaviour for case (4) where X.509
and rfc5280 agreed on "UNDETERMINED", by redefining the result to
be "UNREVOKED", and potentially creates a security problem, and a
new, backwards-incompatible behaviour for a situation where
X.509 and rfc5280 used to agree. Still, the new text does not do
anything about case (3), the only case where X.509 and rfc5280
appear to differ (in a mostly marginal fashion).

A careful implementor, that analyzes NOTE 4 and NOTE 5 from X.509
quoted above in its entirety, should realize that the situation
where X.509 and rfc5280 differ is marginal.

This is because (d>) in NOTE 5 above requires ("shall") that a
critical crlEntryExtension with a semantic beyond "this cert is
revoked"), MUST be additionally included as a critical crlExtension,
with the effect that the entire CRL will have to be ignored by
both X.509 and rfc5280 implementations that do not recognize
the crlExtension.  So all compliant CRLs with a "fancy"
unrecognized critical crlEntryExtension, the accompanying
unrecognized critical crlExtension will cause X.509 and rfc5280
to agree on (3) to return "UNDETERMINED" and require other
CRLs to be checked. 

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 13 Sep 2012 02:33:14 +0200 (CEST)

correction: the proposed new text in -09 creates the potential
security problem here:

> appear to differ (in a mostly marginal fashion).

If the cert under examination is listed on the CRL, and happens to
be the entry with the unrecognized critical CRLEntryExtensions,
then the new text specifies that the cert status is "UNREVOKED",
where X.509 specifies "REVOKED" and rfc5280 specifies "UNDETERMINED".

While the latter might be less efficent, it is at least not wrong.
I believe the behaviour specified by the new text "UREVOKED" to
be dangerously wrong (and completely backwards incompatible).

-Martin

---

From: Piyush Jain <[email-masked]>
Date: Fri, 14 Sep 2012 21:32:48 +0000

Please accept my apologies in advance if I did not understand it correctly.
Is there a difference between "UNREVOKED" and "UNDETERMINED"? I could not find a definition for these terms either in RFC 5280 or in correction draft 09.

I think you are referring to this text in the section 4 of draft-09
"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."

I agree that in this case certificated being referred to, by that entry should be considered revoked. 

> Martin Rex
> Sent: Wednesday, September 12, 2012 5:33 PM
> To: [email-masked]
> Cc: pkix
> Subject: Re: [pkix] 5280bis, v-09
> 
> correction: the proposed new text in -09 creates the potential security
> problem here:
> 
> Martin Rex wrote:
> >
> > and rfc5280 agreed on "UNDETERMINED", by redefining the result to be
> > "UNREVOKED", and potentially creates a security problem, and a new,
> > backwards-incompatible behaviour for a situation where
> > anything about case (3), the only case where X.509 and rfc5280 appear
> > to differ (in a mostly marginal fashion).
> 
> If the cert under examination is listed on the CRL, and happens to be the
> entry with the unrecognized critical CRLEntryExtensions, then the new text
> specifies that the cert status is "UNREVOKED", where X.509 specifies
> "REVOKED" and rfc5280 specifies "UNDETERMINED".
> 
> I believe the behaviour specified by the new text "UREVOKED" to be
> dangerously wrong (and completely backwards incompatible).
> 
> -Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 16 Sep 2012 20:31:08 -0400

Piyush,

In my analysis, 5280 is not saying that the certificate represented by the entry should be considered revoked.

The relying party can get another CRL or other revocation information or can make a decision it makes in the absence of revocation information.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Piyush Jain
Sent: Friday, September 14, 2012 5:33 PM
To: [email-masked]
Cc: pkix
Subject: Re: [pkix] 5280bis, v-09

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Martin Rex
> If the cert under examination is listed on the CRL, and happens to be 
> the entry with the unrecognized critical CRLEntryExtensions, then the 
> new text specifies that the cert status is "UNREVOKED", where X.509 
> specifies "REVOKED" and rfc5280 specifies "UNDETERMINED".
>

---

From: Piyush Jain <[email-masked]>
Date: Mon, 17 Sep 2012 01:09:21 +0000

Santosh - I agree with you analysis.

However, as Martin pointed out, this behavior is inconsistent with X.509.
X.509 says that the certificated specified by the CRL entry should be treated as revoked and it should not affect the processing of other entries in the CRL (unless there a CRL extension that dictates it).

Given that many deployments treat 'unknown' status as being less severe than 'revoked', 5280 introduces slight vulnerability by requiring the CRL to be rejected because of presence of an unknown critical CRL entry extension.

-Piyush
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Sunday, September 16, 2012 5:31 PM
> To: Piyush Jain; [email-masked]
> Cc: pkix
> Subject: RE: [pkix] 5280bis, v-09
> 
> Piyush,
> 
> The relying party can get another CRL or other revocation information or can
> make a decision it makes in the absence of revocation information.
> 
> Piyush Jain
> Is there a difference between "UNREVOKED" and "UNDETERMINED"? I could
> not find a definition for these terms either in RFC 5280 or in correction draft
> 09.
> 
> "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."
>

---

From: [email-masked]
Date: Mon, 17 Sep 2012 09:46:32 +0200

Good catch Martin,

You came back from vacation just in time. :-)

I propose the following:

Replace:

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

with

|     If a CRL contains in a CRL entry a critical CRL entry extension 
|     that the application cannot process, then the application MUST 
|     consider that the certificate identified in that CRL entry is 
|     revoked. 

In order to answer to Piyush, I believe that “unknown” should be used 
rather than “revoked”.

The following example is an illustration:

The status of a given certificate is indicated as “good”, but there is a 
CRL entry with a critical 
CRL entry extension. This entry means (for the applications which 
understand it) : 

"The status which is usually obtained using a database of issued 
certificates has been obtained from CRLs. 
If you really need to take a decision now, it is at your own risk. If you 
can wait, you had better to try again later on".

Your next question will certainly be: so why don’t you use the proposed 
certInfo extension ?

For applications which do not understand this critical CRL entry 
extension, there is no difference.
They get an "unknown" status in both cases.

For applications which understand this critical CRL entry extension it 
provides less benefits 
than the proposed certInfo extension, but it might be quicker to implement 
and it enforces a policy.

Denis

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 17 Sep 2012 10:02:32 -0400

Piyush,

With the proposed 09 text, 5280 is well-aligned with X.509 and the CRL cannot be used.

If the CRL entry extension is non-critical and the application can process it fine.  If the application cannot process it, the entry can be used.

If the CRL entry extension is critical, the new text requires the application to be able to process both the related CRL extension and the entry extension or reject the whole CRL since it cannot process the related CRL extension.

A simple case in point is indirect CRL and CRL issuer CRL entry extension .  Without understanding the extension, application should not use the serial number since it might apply to some other CA.  Note that this is what started the whole discussion.

-----Original Message-----
From: Piyush Jain [mailto:[email-masked]] 
Sent: Sunday, September 16, 2012 9:09 PM
To: Santosh Chokhani; [email-masked]
Cc: pkix
Subject: RE: [pkix] 5280bis, v-09

-Piyush
> The relying party can get another CRL or other revocation information 
> or can make a decision it makes in the absence of revocation information.
> 
> Of Piyush Jain
> not find a definition for these terms either in RFC 5280 or in 
> correction draft 09.
> 
> > > creates a significantly distinct behaviour for case (4) where 
> > > X.509 and rfc5280 agreed on "UNDETERMINED", by redefining the 
> > > result to be "UNREVOKED", and potentially creates a security 
> > > problem, and a new, backwards-incompatible behaviour for a 
> > > situation where
> > be the entry with the unrecognized critical CRLEntryExtensions, then 
> > the new text specifies that the cert status is "UNREVOKED", where 
> > X.509 specifies "REVOKED" and rfc5280 specifies "UNDETERMINED".
> >

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 17 Sep 2012 10:21:30 -0400

This also relates to earlier post I made in response to Piyush.

I assume we are adding the following to the RFC “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.”

In that case, I do not mind adding the following to 5280 (a slight modification to what Denis has:

If an application cannot process a critical extension in the crlEntryExtensions field of an entry that affects only the certificate specified in that entry, as indicated by the absence of a related critical extension in the crlExtensions field, then the certificate identified by the CRL entry shall be considered revoked.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, September 17, 2012 3:47 AM
To: [email-masked]; Piyush Jain
Cc: pkix
Subject: Re: [pkix] 5280bis, v-09

Good catch Martin,

I propose the following:

Replace:

with

In order to answer to Piyush, I believe that “unknown” should be used rather than “revoked”.

The status of a given certificate is indicated as “good”, but there is a CRL entry with a critical
CRL entry extension. This entry means (for the applications which understand it) :

"The status which is usually obtained using a database of issued certificates has been obtained from CRLs.
If you really need to take a decision now, it is at your own risk. If you can wait, you had better to try again later on".

Your next question will certainly be: so why don’t you use the proposed certInfo extension ?

For applications which do not understand this critical CRL entry extension, there is no difference.
They get an "unknown" status in both cases.

For applications which understand this critical CRL entry extension it provides less benefits
than the proposed certInfo extension, but it might be quicker to implement and it enforces a policy.

Denis

> [email-masked]<mailto:[email-masked]>

---

From: [email-masked]
Date: Mon, 17 Sep 2012 16:42:14 +0200

Santosh, Piyush and Martin,

Sorry, I made a mistake when making my proposal this morning. 
I wrote "revoked", but was advocating "unknown".

Based on the latest text proposed from Santosh, I would rather prefer:

If an application cannot process a critical extension in the 
crlEntryExtensions field of an entry 
that affects only the certificate specified in that entry, as indicated by 
the absence of a related 
critical extension in the crlExtensions field, then the status of 
certificate identified by the CRL entry 
shall be considered unkown.

instead of :

If an application cannot process a critical extension in the 
crlEntryExtensions field of an entry 
that affects only the certificate specified in that entry, as indicated by 
the absence of a related 
critical extension in the crlExtensions field, then the certificate 
identified by the CRL entry 
shall be considered revoked.

Denis

De :    Santosh Chokhani <[email-masked]>
A :     "[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>, Piyush Jain <[email-masked]>
Cc :    pkix <[email-masked]>
Date :  17/09/2012 16:21
Objet : RE: [pkix] 5280bis, v-09

I assume we are adding the following to the RFC “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.”
 
In that case, I do not mind adding the following to 5280 (a slight 
modification to what Denis has:
 
If an application cannot process a critical extension in the 
crlEntryExtensions field of an entry that affects only the certificate 
specified in that entry, as indicated by the absence of a related critical 
extension in the crlExtensions field, then the certificate identified by 
the CRL entry shall be considered revoked.
 
[email-masked]
 
Good catch Martin, 

I propose the following: 

Replace: 

with 

Denis

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 17 Sep 2012 10:48:20 -0400

Denis,

I am ok either way (unknown or revoked).  The good thing is that the new text spells things out more clearly.

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 17, 2012 10:42 AM
To: Santosh Chokhani
Cc: [email-masked]; Piyush Jain; pkix
Subject: RE: [pkix] 5280bis, v-09

If an application cannot process a critical extension in the crlEntryExtensions field of an entry
that affects only the certificate specified in that entry, as indicated by the absence of a related
critical extension in the crlExtensions field, then the status of certificate identified by the CRL entry
shall be considered unkown.

instead of :

If an application cannot process a critical extension in the crlEntryExtensions field of an entry
that affects only the certificate specified in that entry, as indicated by the absence of a related
critical extension in the crlExtensions field, then the certificate identified by the CRL entry
shall be considered revoked.

Denis

De :        Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
A :        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Piyush Jain <[email-masked]<mailto:[email-masked]>>
Cc :        pkix <[email-masked]<mailto:[email-masked]>>
Date :        17/09/2012 16:21
Objet :        RE: [pkix] 5280bis, v-09
________________________________

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, September 17, 2012 3:47 AM
To: [email-masked]<mailto:[email-masked]>; Piyush Jain
Cc: pkix
Subject: Re: [pkix] 5280bis, v-09

Good catch Martin,

I propose the following:

Replace:

with

Denis

---

From: Piyush Jain <[email-masked]>
Date: Mon, 17 Sep 2012 14:55:41 +0000

Thanks Denis,

I guess your recommendation is already captured in this text from draft-09.
“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, this recommendation is not aligned with X.509 which recommends that the certificate should be considered revoked.
Santosh’s proposed addition aligns 5280 with X.509.

I’ll be interested in understanding if there are any strong reasons for your proposal for deviating from X.509 on this.

-Piyush

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 17, 2012 7:42 AM
To: Santosh Chokhani
Cc: [email-masked]; Piyush Jain; pkix
Subject: RE: [pkix] 5280bis, v-09

instead of :

Denis

Good catch Martin,

I propose the following:

Replace:

with

Denis

---

From: Piyush Jain <[email-masked]>
Date: Mon, 17 Sep 2012 14:58:01 +0000

Thanks Santosh, your proposed addition will align 5280 with X.509.
We should also remove this text from draft-09.

As this obviously contradicts with your proposed text.

From: Santosh Chokhani [mailto:[email-masked]]
Sent: Monday, September 17, 2012 7:22 AM
To: [email-masked]; [email-masked]; Piyush Jain
Cc: pkix
Subject: RE: [pkix] 5280bis, v-09

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, September 17, 2012 3:47 AM
To: [email-masked]<mailto:[email-masked]>; Piyush Jain
Cc: pkix
Subject: Re: [pkix] 5280bis, v-09

Good catch Martin,

I propose the following:

Replace:

with

Denis

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 17 Sep 2012 10:59:10 -0400

I agree

From: Piyush Jain [mailto:[email-masked]]
Sent: Monday, September 17, 2012 10:58 AM
To: Santosh Chokhani; [email-masked]; [email-masked]
Cc: pkix
Subject: RE: [pkix] 5280bis, v-09

From: Santosh Chokhani [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, September 17, 2012 7:22 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Piyush Jain
Cc: pkix
Subject: RE: [pkix] 5280bis, v-09

Good catch Martin,

I propose the following:

Replace:

with

Denis

---

From: Piyush Jain <[email-masked]>
Date: Mon, 17 Sep 2012 15:06:00 +0000

My recommendation would be to go with ‘revoked’ on this unless we can explicitly spell out why we chose ‘unknown’ to override X.509.

I just want to avoid the situation where someone raises this issue again in a few years that 5280 is inconsistent with X.509 without any apparent reason.

From: Santosh Chokhani [mailto:[email-masked]]
Sent: Monday, September 17, 2012 7:48 AM
To: [email-masked]
Cc: [email-masked]; Piyush Jain; pkix
Subject: RE: [pkix] 5280bis, v-09

Denis,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Monday, September 17, 2012 10:42 AM
To: Santosh Chokhani
Cc: [email-masked]<mailto:[email-masked]>; Piyush Jain; pkix
Subject: RE: [pkix] 5280bis, v-09

instead of :

Denis

Good catch Martin,

I propose the following:

Replace:

with

Denis

---

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

Piyush Jain wrote:
>
> Is there a difference between "UNREVOKED" and "UNDETERMINED"?
> I could not find a definition for these terms either in RFC 5280
> or in correction draft 09. 

The meaning of these are described in rfc5280, section 6.3.2 (b)

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

      (b)  cert_status:  This variable contains the status of the
           certificate.  This variable may be assigned one of the
           following values: unspecified, keyCompromise, cACompromise,
           affiliationChanged, superseded, cessationOfOperation,
           certificateHold, removeFromCRL, privilegeWithdrawn,
           aACompromise, the special value UNREVOKED, or the special
           value UNDETERMINED.  This variable is initialized to the
           special value UNREVOKED.

UNDETERMINED means that the status of a certificate could not yet
be determined because no CRL that has been confirmed to be authoritative
and which the implementation could successfully process has been
processed yet.

UNREVOKED means that an authoritative CRL for the cert has been successfully
processed, and the cert was not listed on this CRL (successfully processed
included that no unknown critical crlExtensions and crlEntryExtensions
were encountered).

Side note, I'm wondering what ReasonCode "removeFromCRL" is supposed to
mean with respect to X.509's "it shall assume that, at a minimum,
the identified certificate has been revoked and is no longer valid".
I assumed that "removedFromCRL" is an explicit UNREVOKED status.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 17 Sep 2012 17:31:18 +0200 (CEST)

Evidently, I am not a (carful) implementor myself.  With my mind focused
on the crlEntryExtension requirements, I missed the NOTE 4 (b>) requirement
that applies to the processing of unrecognized critical crlExtensions:

> d>  field regardless of where the extension is placed in the CRL.

which means that there is another difference between X.509 and rfc5280
with respect to processing of CRLs that contain an unrecognized critical
crlExtension. 

> to agree on (3) to return "UNDETERMINED" and require other

I agree with Santosh that these X.509 requirements interfere quite badly
with the "compression scheme" for the issuer name of indirect CRLs.

So the X.509 semantics are somewhat from the problem space rather than the
solution space, and the rfc5280 semantics (unconditionally ignore CRL)
are _theoretically_ safer.  In practice, however, X.509 factors in
common "local policies", one of which is "best effort, soft fail
revocation check", and rfc5280 is ignorant of / defying that fairly common
"local policy" (which sometimes is an implementation characteristic
rather than something the consumer of the technology consciously asks for).

-Martin

---

From: [email-masked]
Date: Mon, 17 Sep 2012 21:57:06 +0200

Piyush,

I have been involved in the writing of ISO standards, including X.509. 

Sharon has been even more involved than myself, since she has been 
the editor during some period of time .

There is something important to know about ISO standards:
 
The text placed under a NOTE is *not* normative.

I copied and pasted the text from X.509 and we have the following:

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.

So this text is not normative.  We can say something different in RFC 5280 
and this will *not* be a contradiction.

So the real question is simply : what makes sense to say about the 
treatment of the crlEntryExtensions field ?

I believe (or I hope) we are close to a agreement, except whether we 
should use the word "revoked" or "unknown" 
in the last word on the sentence proposed today.

So the two options are:

A)  If an application cannot process a critical extension in the 
crlEntryExtensions field of an entry 
that affects only the certificate specified in that entry, as indicated by 
the absence of a related 
critical extension in the crlExtensions field, then the status of 
certificate identified by the CRL entry 
shall be considered as unkown. 

B) If an application cannot process a critical extension in the 
crlEntryExtensions field of an entry 
that affects only the certificate specified in that entry, as indicated by 
the absence of a related 
critical extension in the crlExtensions field, then the status of 
certificate identified by the CRL entry 
shall be considered as revoked. 

I believe that A) is better, but the difference is tenuous. See a new 
example below. 

What do you (and others) think ?

Denis

===================================================================================

CRL entry extension. 

Whatever, this crlEntryExtension means, if an application considers that 
the status of the certificate for the entry 
is  "unknown", it can attempt to use an OCSP service, if available; but if 
an application considers that the status of 
the certificate for the entry is "revoked ", it will not attempt to call 
it.

As an example, this critical CRL entry extension means (only for 
applications which understand it) : 

"The CRL issuer of this CRL has not been able to obtain in real time the 
status of the certificates using a database 
of issued certificates. Rather than not issuing the CRL and creating a 
denial of service for all verifiers, this CRL has 
been issued,  but is not "fresh". If you really need to take a decision 
now, you can use this CRL but at your own risk. 
If you can access an OCSP server, you might be able to get a fresher 
status. Otherwise, if you can wait, you can 
try again later on". 

De :    Piyush Jain <[email-masked]>
A :     Santosh Chokhani <[email-masked]>, "[email-masked]" 
<[email-masked]>
Cc :    "[email-masked]" <[email-masked]>, pkix <[email-masked]>
Date :  17/09/2012 17:06
Objet : RE: [pkix] 5280bis, v-09

My recommendation would be to go with ‘revoked’ on this unless we can 
explicitly spell out why we chose ‘unknown’ to override X.509.
 
I just want to avoid the situation where someone raises this issue again 
in a few years that 5280 is inconsistent with X.509 without any apparent 
reason.

Denis,
 
I am ok either way (unknown or revoked).  The good thing is that the new 
text spells things out more clearly.

instead of : 

Denis 

  

  
  
Good catch Martin, 

I propose the following: 

Replace: 

with 

Denis

---

From: Peter Yee <[email-masked]>
Date: Mon, 17 Sep 2012 13:06:32 -0700

Denis,
I much prefer to return a status of "unknown" which is, as you point out in
your example below, more accurate.  Returning a status of "revoked" while
certainly preventing the relying party from mistakenly trusting the
certificate, might have unintended consequences as well.  An unknown status
should suffice to prevent using the certificate without having immediate
implications beyond that.

-Peter

On 9/17/12 12:57 PM, "[email-masked]" <[email-masked]> wrote:

Piyush,

 

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.

So the real question is simply : what makes sense to say about the treatment
of the crlEntryExtensions field ?

I believe (or I hope) we are close to a agreement, except whether we should
use the word "revoked" or "unknown"
in the last word on the sentence proposed today.

So the two options are:

Denis

============================================================================
=======

The status of a given certificate is indicated as ³good², but there is a CRL
entry with a critical
CRL entry extension.

Whatever, this crlEntryExtension means, if an application considers that the
status of the certificate for the entry
is  "unknown", it can attempt to use an OCSP service, if available; but if
an application considers that the status of
the certificate for the entry is "revoked ", it will not attempt to call it.

"The CRL issuer of this CRL has not been able to obtain in real time the
status of the certificates using a database
of issued certificates. Rather than not issuing the CRL and creating a
denial of service for all verifiers, this CRL has
been issued,  but is not "fresh". If you really need to take a decision now,
you can use this CRL but at your own risk.
If you can access an OCSP server, you might be able to get a fresher status.
Otherwise, if you can wait, you can
try again later on".

My recommendation would be to go with Œrevoked¹ on this unless we can
explicitly spell out why we chose Œunknown¹ to override X.509.
 
I just want to avoid the situation where someone raises this issue again in
a few years that 5280 is inconsistent with X.509 without any apparent
reason.
 
From: Santosh Chokhani [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Monday, September 17, 2012 7:48 AM
To: [email-masked]
Cc: [email-masked]; Piyush Jain; pkix
Subject: RE: [pkix] 5280bis, v-09
 
Denis,

From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked]] <mailto:[mailto:[email-masked]]>
Sent: Monday, September 17, 2012 10:42 AM
To: Santosh Chokhani
Cc: [email-masked] <mailto:[email-masked]> ; Piyush Jain; pkix
Subject: RE: [pkix] 5280bis, v-09

instead of : 

Denis 

De :        Santosh Chokhani <[email-masked]
<mailto:[email-masked]> >
A :        "[email-masked] <mailto:[email-masked]> "
<[email-masked] <mailto:[email-masked]> >, "[email-masked]
<mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, Piyush Jain
<[email-masked] <mailto:[email-masked]> >
Cc :        pkix <[email-masked] <mailto:[email-masked]> >
Date :        17/09/2012 16:21
Objet :        RE: [pkix] 5280bis, v-09

I assume we are adding the following to the RFC ³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.²

If an application cannot process a critical extension in the
crlEntryExtensions field of an entry that affects only the certificate
specified in that entry, as indicated by the absence of a related critical
extension in the crlExtensions field, then the certificate identified by the
CRL entry shall be considered revoked.
  
From: [email-masked] <mailto:[email-masked]>
[mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of
[email-masked] <mailto:[email-masked]>
Sent: Monday, September 17, 2012 3:47 AM
To: [email-masked] <mailto:[email-masked]> ; Piyush Jain
Cc: pkix
Subject: Re: [pkix] 5280bis, v-09
  
Good catch Martin, 

I propose the following:

Replace: 

with 

In order to answer to Piyush, I believe that ³unknown² should be used rather
than ³revoked². 

The status of a given certificate is indicated as ³good², but there is a CRL
entry with a critical
CRL entry extension. This entry means (for the applications which understand
it) : 

Your next question will certainly be: so why don¹t you use the proposed
certInfo extension ?

For applications which do not understand this critical CRL entry extension,
there is no difference.
They get an "unknown" status in both cases.

Denis 

> (get them here http://www.itu.int/rec/T-REC-X.509
<http://www.itu.int/rec/T-REC-X.509> ):
> [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: [email-masked] (Martin Rex)
Date: Mon, 17 Sep 2012 22:58:30 +0200 (CEST)

[email-masked] wrote:
>
> So the two options are:
> 
> A) If an application cannot process ... critical crlEntryExtension
>    ... then the status of certificate identified by the CRL entry 
> B) If an application cannot process ... critical crlEntryExtension
>    then the status of certificate identified by the CRL entry 

rfc5280 currently specifies (A), X.509 explicitly assumes (B).
Personally, I'm OK with (A), I agree with Santosh that the issuer name
compression scheme for crlEntryExtensions interferes with (B).

But what REALLY concerns me is, what about the status of certs that
are *NOT* listed on the CRL.  It is for this situation where the
guidance in NOTE 4 and NOTE 5 in X.509 creates a problem, in where
the proposed addition in -09 (ignore only that crlEntry with the
unrecognized critical crlEntryExtension) would create a problem.

rfc5280 says (and agrees with X.509) that CRL with an unrecognized
critical crlExtension *or* unrecognized critical crlEntryExtension
shall not be used to determine the status of a certificate that
is *NOT* listed on the CRL.

> The text placed under a NOTE is *not* normative.

Now that you mentioned this, what is stated in the beginning of
the document (page ii) is this:

                                  NOTE

    [...]

    Compliance with this Recommendation is voluntary. However,
    the Recommendation may contain certain mandatory provisions
    (to ensure e.g., interoperability or applicability) and
*>  compliance with the Recommendation is achieved when all of
*>  these mandatory provisions are met. The words "shall" or some
*>  other obligatory language such as "must" and the negative
*>  equivalents are used to express requirements.
    The use of such words does not suggest that compliance with the
    Recommendation is required of any party.

I don't see where this document says that explicit requirements ("shall")
placed under a NOTE would not be normative.  If it was meant non-normative,
then "should" rather than "shall" would have to be used.

You seem to say that a NOTE within normative sections of an ISO
spec always is non-normative, even when it uses normative language
(= absolute requirements "shall" and "must not")? 

To me, such an interpretation appears neither intuitive nor reasonable,
and actually amounts to logical nonsense.

The semantics of the criticality flag for a (certificate) extension
seems to be first defined in Section 7 of ITU-T T-REC X.509 08/2005,
bottom of page 12:

                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.

if NOTE 4 was really non-normative, then it could not possibly change the
semantics of an unrecognized critical crlEntryExtension to be treated
differently ("shall assume the identified certificate to be ignored")
-- in which case a non-normative statement to that effect would be
a clear logical contradiction.

The processing of unrecognized critical crlEntryExtensions and unrecognized
critical crlExtensions is mis-specified, and any presumption
"Text under NOTE in an ISO-Standard are not meant to be normative"
is *NOT* going to help in this situation in determining
what should be the correct behaviour.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 17 Sep 2012 23:04:33 +0200 (CEST)

Ooops, corrected paragraph (from my previous posting) below:

But what REALLY concerns me is, what about the status of certs that
are *NOT* listed on the CRL.  It is for this situation where the
guidance in NOTE 4 and NOTE 5 in X.509 creates _no_ problem, whereas
the proposed addition in -09 (ignore only that crlEntry with the
unrecognized critical crlEntryExtension) will create a problem.

-Martin

---

From: Piyush Jain <[email-masked]>
Date: Mon, 17 Sep 2012 21:34:11 +0000

Denis,

Thanks for the little primer on ISO standards.
I just assumed that SHALL in the note implies that the text in normative.

Completely agree that the difference is tenuous. As I said, my only reason for proposing ‘revoked’ was to stay aligned with X.509 because a deviation might cause implementers to wonder about the reasons why 5280 chose to deviate from X.509.
I do not think that this is a strong reason so I do not have any objection to option B that you proposed below.

-Piyush

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 17, 2012 12:57 PM
To: Piyush Jain
Cc: [email-masked]; pkix; Santosh Chokhani
Subject: RE: [pkix] 5280bis, v-09

Piyush,

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.

So this text is not normative.  We can say something different in RFC 5280 and this will *not* be a contradiction.

So the real question is simply : what makes sense to say about the treatment of the crlEntryExtensions field ?

I believe (or I hope) we are close to a agreement, except whether we should use the word "revoked" or "unknown"
in the last word on the sentence proposed today.

So the two options are:

A)  If an application cannot process a critical extension in the crlEntryExtensions field of an entry
that affects only the certificate specified in that entry, as indicated by the absence of a related
critical extension in the crlExtensions field, then the status of certificate identified by the CRL entry
shall be considered as unkown.

B) If an application cannot process a critical extension in the crlEntryExtensions field of an entry
that affects only the certificate specified in that entry, as indicated by the absence of a related
critical extension in the crlExtensions field, then the status of certificate identified by the CRL entry
shall be considered as revoked.

I believe that A) is better, but the difference is tenuous. See a new example below.

Denis

Whatever, this crlEntryExtension means, if an application considers that the status of the certificate for the entry
is  "unknown", it can attempt to use an OCSP service, if available; but if an application considers that the status of
the certificate for the entry is "revoked ", it will not attempt to call it.

As an example, this critical CRL entry extension means (only for applications which understand it) :

"The CRL issuer of this CRL has not been able to obtain in real time the status of the certificates using a database
of issued certificates. Rather than not issuing the CRL and creating a denial of service for all verifiers, this CRL has
been issued,  but is not "fresh". If you really need to take a decision now, you can use this CRL but at your own risk.
If you can access an OCSP server, you might be able to get a fresher status. Otherwise, if you can wait, you can
try again later on".

De :        Piyush Jain <[email-masked]<mailto:[email-masked]>>
A :        Santosh Chokhani <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc :        "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, pkix <[email-masked]<mailto:[email-masked]>>
Date :        17/09/2012 17:06
Objet :        RE: [pkix] 5280bis, v-09
________________________________

To: [email-masked]<mailto:[email-masked]>

Denis,

instead of :

Denis

Good catch Martin,

I propose the following:

Replace:

with

Denis

---

From: [email-masked] (Martin Rex)
Date: Mon, 17 Sep 2012 23:43:59 +0200 (CEST)

Ooops, another paragraph with an error (correct below):

differently ("shall assume the identified certificate to be invalid")

-Martin

PS: I'm sorry.  I'm sending replies out too quickly, which is partially
motivated by my (simple) MUA that prevents me from accessing my inbox while
writing a reply, and it appears I should either fix my MUA behaviour or
rethink my MUA choice...