Subject: [pkix] once again, with feeling ...

From: Stephen Kent <[email-masked]>
Date: Wed, 03 Oct 2012 10:43:01 -0400

Thank for the feedback. Obviously my text was incorrect in that an RP 
that can't process
a CRL extension has no way of determining if that extension is related 
to a CRL entry extension
that it also cannot process.  Also, there was no intent to change the 
requirements re dealing
with an unknown CRL (vs. CRL entry) extension. Note that this text 
augments Section 5.3 of 5280,
which deals only with processing of CRL _entry_ extensions.

Based on feedback from several messages, I have revised the text 
slightly.  Here is my next pass.

Steve
------

I propose the following text, in lieu of the current "new second 
paragraph" that appears in Section 4 of 
draft-ietf-pkix-rfc5280-clarifications-09.txt:

A critical extension in the crlEntryExtensions field of an entrySHALL 
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. If a relying party is unable to process a 
critical crlEntryExtension, the relying party is faced with a difficult 
choice.

1-The relying party may assume that the the CRLEntry is associated with 
the CA that issued the CRL, and thus treat that certificate as revoked. 
If the CRLEntry refers to a certificate issued by a different CA, the 
relying party will treat a valid certificate as being revoked.

2-The relying party, realizing that it cannot accurately determine if 
the CRLEntry is associated with the CA that issued the CRL, may choose 
to treat that certificate as having an undetermined revocation status. 
If the relying party is able to consult other sources of certificate 
revocation status (e.g., OCSP) it may use those sources instead. If not, 
the relying party then accepts or rejects the certificate as a matter of 
local policy.

3-The relying party may view the CRLEntry as being associated with an 
undetermined CA, and treat all certificates with that serialNumber as 
being revoked. This behavior runs the risk of treating a number of valid 
certificates as revoked.

Because options one and three have associated risks, this document does 
not specify relying party behavior under the circumstances noted above. 
A relying party SHOULD accept or reject certificates with the indicated 
serialNumber as a matter of local policy.

---

From: Piyush Jain <[email-masked]>
Date: Wed, 3 Oct 2012 16:02:15 +0000

Steve,

I'm a little confused about the original issues that this proposed change is attempting to address.

I don't think that tying a CRL entry to the cert issuer is the problem here. That is addressed clearly by "Issuing Distribution Point" and "Certificate Issuer" extensions.

Your proposal below assumes that a critical CRL entry extension (without an associated CRL extension) can indicate that the CRL entry refers to a certificate not issued by the CRL issuer.  One can argue that this provides more flexibility to future CRL entry extension designers, but IMHO it would be bad design and just complicate the processing of CRLs unnecessarily.

As I understood the original problem: Should the RP use a CRL entry with unknown critical extension for revocation status check or not?

-Piyush

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Wednesday, October 03, 2012 7:43 AM
To: pkix
Subject: [pkix] once again, with feeling ...

Thank for the feedback. Obviously my text was incorrect in that an RP that can't process
a CRL extension has no way of determining if that extension is related to a CRL entry extension
that it also cannot process.  Also, there was no intent to change the requirements re dealing
with an unknown CRL (vs. CRL entry) extension. Note that this text augments Section 5.3 of 5280,
which deals only with processing of CRL entry extensions.

Based on feedback from several messages, I have revised the text slightly.  Here is my next pass.

Steve
------

I propose the following text, in lieu of the current "new second paragraph" that appears in Section 4 of draft-ietf-pkix-rfc5280-clarifications-09.txt:

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. If a relying party is unable to process a critical crlEntryExtension, the relying party is faced with a difficult choice.

1-  The relying party may assume that the the CRLEntry is associated with the CA that issued the CRL, and thus treat that certificate as revoked. If the CRLEntry refers to a certificate issued by a different CA, the relying party will treat a valid certificate as being revoked.

2-  The relying party, realizing that it cannot accurately determine if the CRLEntry is associated with the CA that issued the CRL, may choose to treat that certificate as having an undetermined revocation status. If the relying party is able to consult other sources of certificate revocation status (e.g., OCSP) it may use those sources instead. If not, the relying party then accepts or rejects the certificate as a matter of local policy.

3-  The relying party may view the CRLEntry as being associated with an undetermined CA, and treat all certificates with that serialNumber as being revoked. This behavior runs the risk of treating a number of valid certificates as revoked.

Because options one and three have associated risks, this document does not specify relying party behavior under the circumstances noted above. A relying party SHOULD accept or reject certificates with the indicated serialNumber as a matter of local policy.

---

From: [email-masked]
Date: Wed, 3 Oct 2012 18:27:07 +0200

Steve,

Thank you for the new proposal. It is certainly better than the previous 
one.

I have reused your text and rearranged it. 

Here is a new strawman proposal:

===================================================================================
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. 
If a relying party is unable to process a critical crlEntryExtension, the 
relying party cannot accurately determine 
the revocation status of the certificate identified in that CRLEntry, 
unless the relying party is able to consult 
other sources of certificate revocation status (e.g., OCSP) for the 
certificate being checked. In such a case, it 
may obtain a reliable revocation status. Otherwise:
If the relying party is able to know (using out of bands means) that the 
CRLEntry is associated with the CA that issued 
the CRL, then the relying party SHALL consider that the revocation status 
of the certificate is revoked.
If the relying party is unable to know (even using out of bands means) 
whether the CRLEntry is associated with the CA 
that issued the CRL, then the relying party is faced with a difficult 
choice. However, since most CAs are using large 
certificate serial numbers a collision between such numbers is rather 
unlikely. So it is more likely that the certificate 
serial number relates to the right CA and for that reason this document 
RECOMMENDS to consider that certificate as having 
a revoked revocation status.  However, a local policy may dictate 
otherwise.
=======================================================================================================
Denis

De :    Stephen Kent <[email-masked]>
A :     pkix <[email-masked]>
Date :  03/10/2012 16:43
Objet : [pkix] once again, with feeling ...
Envoyé par :    [email-masked]

Thank for the feedback. Obviously my text was incorrect in that an RP that 
can't process
a CRL extension has no way of determining if that extension is related to 
a CRL entry extension
that it also cannot process.  Also, there was no intent to change the 
requirements re dealing
with an unknown CRL (vs. CRL entry) extension. Note that this text 
augments Section 5.3 of 5280,
which deals only with processing of CRL entry extensions. 

Based on feedback from several messages, I have revised the text slightly. 
 Here is my next pass.

Steve
------

I propose the following text, in lieu of the current “new second 
paragraph” that appears in Section 4 of 
draft-ietf-pkix-rfc5280-clarifications-09.txt:
 
A critical extension in the crlEntryExtensions field of an entry SHALL 
 
1-  The relying party may assume that the the CRLEntry is associated with 
the CA that issued the CRL, and thus treat that certificate as revoked. If 
the CRLEntry refers to a certificate issued by a different CA, the relying 
party will treat a valid certificate as being revoked.
2-  The relying party, realizing that it cannot accurately determine if 
the CRLEntry is associated with the CA that issued the CRL, may choose to 
treat that certificate as having an undetermined revocation status. If the 
relying party is able to consult other sources of certificate revocation 
status (e.g., OCSP) it may use those sources instead. If not, the relying 
party then accepts or rejects the certificate as a matter of local policy.
3-  The relying party may view the CRLEntry as being associated with an 
undetermined CA, and treat all certificates with that serialNumber as 
being revoked. This behavior runs the risk of treating a number of valid 
certificates as revoked.
 
Because options one and three have associated risks, this document does 
not specify relying party behavior under the circumstances noted above. A 
relying party SHOULD accept or reject certificates with the indicated 
serialNumber as a matter of local policy.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Stephen Kent <[email-masked]>
Date: Wed, 03 Oct 2012 13:50:58 -0400

Piyush,

Note that there is already aCertificate Issuer CRL entry extension, whic 
is critical,
contrary to what you stated in your message. So, yes, tying the cert to 
the issuer via a CRL entry extension is a legitimate focus of this text.

Steve

---

From: Piyush Jain <[email-masked]>
Date: Wed, 3 Oct 2012 18:15:46 +0000

Steve,

Certificate Issuer is related to Issuing Distribution point CRL extension.
If the RP can process IDP(with indirectCRL flag), it should also be able to process Certificate Issuer.

Your text is dealing with the case where there is an unrecognized critical CRL entry extension without any unrecognized critical CRL extension.

So the question is - do we want to encourage creation of CRL entry extensions (without any associated CRL extension) that affect the meaning of whole CRL as opposed just the meaning of that entry.

Please note that such a behavior would contradict the following text from section 5.2.5

If the distributionPoint field is absent, the CRL MUST contain entries for all revoked unexpired certificates issued by the CRL issuer, if any, within the scope of the CRL.

From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, October 03, 2012 10:51 AM
To: Piyush Jain
Cc: pkix
Subject: Re: [pkix] once again, with feeling ...

Piyush,

Note that there is already a Certificate Issuer CRL entry extension, whic is critical,
contrary to what you stated in your message. So, yes, tying the cert to the issuer via a CRL entry extension is a legitimate focus of this text.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 03 Oct 2012 14:21:18 -0400

Denis,

The new text in your proposed revision starts with a sentence that is 4 
lines long!
We're trying to make statements that are easier for readers to 
understand, so let's
not go for long sentences.

Your second proposed paragraph introduces a completely new topic, i.e., 
unspecified
o-o-b identification of the issuer related to the CRL entry in 
question.  I do not want
to include new topics this late in the process. Also, if the RP has 
access to such o-o-b info,
lI think we are in the realm of local policy anyway.

The final paragraph is another whopping long sentence, and it also 
introduces new topics,
i e., CA serial number conventions. This is not something I want to deal 
with at this stage,
and the assumption of large (pseudo randomness is really the relevant 
property here, not
mere size) serial numbers appears nowhere in 5280.

I prefer my text.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 03 Oct 2012 14:29:43 -0400

On 10/3/12 2:15 PM, Piyush Jain wrote:
> If the RP can process IDP(with indirectCRL flag), it should also be 
> able to process Certificate Issuer
>
it is related to IDP, but it's presence is optional in an indirect CRL.
>
> .Your text is dealing with the case where there is an unrecognized 
> critical CRL entry extension without any unrecognized critical CRL 
> extension.
>
yes, so?
>
> So the question is -- do we want to encourage creation of CRL entry 
> extensions (without any associated CRL extension) that affect the 
> meaning of whole CRL as opposed just the meaning of that entry.
>
that is not the question. Without creating a new CRL entry extension we 
already face the problem
that an RP might recognize the IDP extension, but not the Cert issuer 
entry xtension, hence the
need for the text.

Steve

---

From: Piyush Jain <[email-masked]>
Date: Wed, 3 Oct 2012 19:54:42 +0000

Are you saying that a compliant RP can process IDP with indirectCRL Boolean on and choose not to process "CRL Issuer" extension?

This is what 5280 says:

If the scope of the CRL only includes certificates issued by the CRL issuer, then the indirectCRL boolean MUST be set to FALSE. Otherwise, if the scope of the CRL includes certificates issued by one or more authorities other than the CRL issuer, the indirectCRL boolean MUST be set to TRUE.  The authority responsible for each entry is indicated by the certificate issuer CRL entry extension(Section 5.3.3).

While it is not explicit in the above text, my interpretation is that if an RP claims to process IDP, it should also process "Certificate Issuers".
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, October 03, 2012 11:30 AM
To: Piyush Jain
Cc: pkix
Subject: Re: [pkix] once again, with feeling ...

Certificate Issuer is related to Issuing Distribution point CRL extension.
If the RP can process IDP(with indirectCRL flag), it should also be able to process Certificate Issuer
it is related to IDP, but it's presence is optional in an indirect CRL.

.Your text is dealing with the case where there is an unrecognized critical CRL entry extension without any unrecognized critical CRL extension.
yes, so?

So the question is - do we want to encourage creation of CRL entry extensions (without any associated CRL extension) that affect the meaning of whole CRL as opposed just the meaning of that entry.
that is not the question. Without creating a new CRL entry extension we already face the problem
that an RP might recognize the IDP extension, but not the Cert issuer entry xtension, hence the
need for the text.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 03 Oct 2012 16:14:33 -0400

On 10/3/12 3:54 PM, Piyush Jain wrote:
>
> Are you saying that a compliant RP can process IDP with indirectCRL 
> Boolean on and choose not to process "CRL Issuer" extension?
>
No. I am saying that a sloppy RP might be programmed to understand the 
IDP extension and indirectCRL Boolean, but might not understand the CRL 
Issuer entry extension.
>
> This is what 5280 says:
>
> If the scope of the CRL only includes certificates issued by the CRL 
> issuer, then the indirectCRL boolean MUST be set to FALSE. Otherwise, 
> if the scope of the CRL includes certificates issued by one or more 
> authorities other than the CRL issuer, the indirectCRL boolean MUST be 
> set to TRUE.  The authority responsible for each entry is indicated by 
> the certificate issuer CRL entry extension(Section 5.3.3).
>
> While it is not explicit in the above text, my interpretation is that 
> if an RP claims to process IDP, it should also process "Certificate 
> Issuers".
>
We live in an era when a major vendor still does not support the name 
constraints extension,
and thus will reject certs with that extension marked critical, despite 
the fact that this
cert extension has been around for well over a decade. Given this real 
world example, we ought
not assume much re 5280 (or 3280, or 2459) compliance, especially when 
it involves multiple extensions
and flags, as is the case here.

Steve

---

From: Denis Pinkas Bull <[email-masked]>
Date: Thu, 04 Oct 2012 16:11:28 +0200

Steve,

Please reconsider your position in the light of the following explanations:

In my proposal, there is a graduation with serial processing rules 
rather than a choice between three parallel alternatives.

If the RP is unable to process a critical crlEntryExtension then:

    1) Check if there is another source of information available, like OCSP
    2) Check if there is a local policy states which that the CRL issuer 
is only taking care
        of the certificates from one CA.
    3) and finally, if none of the two previous cases provided an 
answer, consider the probability
        of serial number collisions and make the decision according to 
probability rules.

I have reconsidered my text proposal in the light of your comments.

I==================================================================================

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.

If a relying party is unable to process a critical crlEntryExtension, 
then the
relying party cannot accurately determine the revocation status of the 
certificate
identified in that CRLEntry, unless it is able to consult other sources of
certificate revocation status (e.g., OCSP).

If the relying party is able to know (using a local policy) that the 
CRLEntry
is associated with the CA that issued the CRL, then the relying party SHALL
consider that the revocation status of the certificate is revoked.

If the relying party is unable to know whether the CRLEntry is 
associated with
the CA that issued the CRL, then the relying party is faced with a 
difficult choice.

However, most CAs are using large random certificate serial numbers and 
thus
a collision between such numbers is rather unlikely. So it is more likely
that the certificate serial number relates to the right CA and for that 
reason
this document RECOMMENDS to consider that certificate as having a revoked
revocation status.In such case the relying party will treat a valid 
certificate
as being revoked.

> Denis,
>
> The new text in your proposed revision starts with a sentence that is 
> 4 lines long!
> Your second proposed paragraph introduces a completely new topic, 
> i.e., unspecified
> i e., CA serial number conventions. This is not something I want to 
> deal with at this stage,

---

From: Stephen Kent <[email-masked]>
Date: Thu, 04 Oct 2012 12:01:41 -0400

Denis,

The 3 alternatives I provided were intended only to motivate the 
decision to allow RPs to
use local policy to decide how to handle this messy situation. They were 
not intended to
be an algorithmic processing list for RP reference.

Nonetheless, unless there is a show of WG consensus for this approach, 
this is moot,
as per Russ's message yesterday.

Steve

On 10/4/12 10:11 AM, Denis Pinkas Bull wrote:
>    2) Check if there is a local policy states which that the CRL 
> issuer is only taking care

---

From: [email-masked] (Martin Rex)
Date: Sat, 6 Oct 2012 04:48:28 +0200 (CEST)

Stephen Kent wrote:
> constraints extension, and thus will reject certs with that extension
> marked critical,

Perfectly PKIX-compliant behaviour.

It's not only that one vendor which will reject certs with name constraints
that are marked critical, there a number of other, perfectly compliant
PKIX implementations that will reject such certs.

openssl below version 1.0.0 will also reject certs with critical
name constraints.  And the installed base of openssl-0.9.X is **HUGE**
(might actually be larger than the number of iPhones,iPods,iPads and Macs
combined).

>
> despite the fact that this cert extension has been around for well
> over a decade.

Other than your message asserts, support for name constraints is
PURELY optional, in X.509 and PKIX.   

While the wording of X.509 and PKIX suggests that support for name constraints
on the "directory name" is required (and support for all subject alt names
is explicitly optional), the specification for processing of name constraints
for "directory name" is incomplete (underspecified), which defacto kills
it status as a required feature.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Sat, 6 Oct 2012 04:55:00 +0200 (CEST)

Stephen Kent wrote:
> Piyush Jain wrote:

That seems to be a perfectly valid&conforming implementation option.

An RP that supports the IDP crlExtension, but not the CertificateIsser
crlEntryExtension, would not be allowed to use a CRL with the 
indirectCRL Boolean asserted (=TRUE) to determine the status of any certs.

-Martin