Subject: [pkix] 5280bis

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Sep 2012 17:30:14 -0400

I am in favor of discussing how to improve the CRL extension text that 
we just added.

I am not as concerned about whether we are in perfect alignment with 
X.509. In general
it is preferable to not introduce differences between the IETF and ITU-T 
standards. But we
have had such differences in the past, when there were good reasons. For 
example, PKIX
has always required the next update field to be present, since it's 
omission was a serious
error in the X.509 standard.

I believe that the example provided by indirect CRL entries is the 
principle motivation to
clarify the wording in 5280. The "safe" interpretation is to treat the 
serial number of
the cert in a CRL as being from the set of certs issued by the CA that 
issued
the CRL. Unfortunately, this is also a bad interpretation when the cert 
serial number
is supposed to be associated with a different CA, as indicated by this 
CRL entry extension.

Perhaps this should be viewed as a good reason to NOT use this "feature" 
unless the CA knows
that all RPs can interpret the critical CRL entry extension in question.

Anyway, I'd like to see this discussion focus on what appears to be the 
principle
issue, i.e., the merits of playing it safe vs. shooting ones self in the 
foot, rather
than a discussion of whether a rewording will cause 5280 to deviate from 
the current version
of X.509.

Steve

---

From: [email-masked] (Martin Rex)
Date: Tue, 18 Sep 2012 01:04:13 +0200 (CEST)

> I am in favor of discussing how to improve the CRL extension text that 

I'm actually confused about what particular change in semantics
(for "using a CRL to determine the status of a certificate") is
desired, and I currently still doubt that rfc5280 semantics and text
need to be change or should be changed.

So while proposing specific text has its advantages, I would appreciate
if any proposal would state which particular scenario that text is
supposed to affect, what the assumed current semantics is, and what
the assumed behaviour specified by the proposed text is.

... so that is becomes easier to verify that the proposed text change
is consistent with the desired semantics.

The relevant original text in rfc5280 says:

     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.

and the term "any certificates" means it applies to determining the
cert status in both situations, when the given cert is listed on the CRL,
and when the given cert is not listed on the CRL.
To me, this looks safe when ignoring "fail soft" RPs.

The proposed new -09 text has two contradictory statements:

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

This change reduces the situation where is CRL is "not (to be) used"
to determine the status of a cert to those certs that are explicitly
listed and accompanied by an unrecognized critical crlEntryExtension.

So the changed paragraph will no longer apply to checking the status
of a certificate that is *NOT* listed on the CRL.

The additional paragraph creates a new inconsistency:

|     A critical extension in the crlEntryExtensions field of an entry
|     SHALL affect only the certificate specified in that entry, unless
|     there is a related critical extension in the crlExtensions field
|     that advertises a special treatment for it.  In order to use such
|     a CRL, the relying party MUST be able to process both the
|     crlEntryExtension and the related crlExtension.

The first sentence limits the "do not use CRL to determine status
of the certificate" to CRLs with an additional unrecognized critical
crlExtension, and "SHALL affect only" implies that using a CRL without
a critical crlExtension, but with unrecognized critical crlEntryExtensions
is OK to determine the status of a cert that is _not_ listed on the CRL.

The meaning of the second sentence in the new paragraph "In order to use..."
seriously confuses me.  Either this requirement is a self-contained statement,
then it would completely undo the removal of the rfc5280 "NOT use that CRL
to determine the status of any certificates" _plus_ nullify the "only"
in "SHALL affect only" in the 1st sentence of the new paragraph,
and imply the original rfc5280 "MUST NOT use that CRL to determine the
status of any certificate" for CRLs with an unrecognized critical
crlEntryExtension.

Or the second sentence it is dependent on limited scope of the first
sentence "unless there is a related critical extension in the
crlExtensions field", in which case the "SHALL affect only" implies
that it is valid to use the CRL to determine the status of certificates
that are _not_ listed on the CRL (in spite of the presence of an
unrecognized critical crlEntryExtension in at least on crlEntry,
but no critical crlExtension accompanying it)
--something which could IMO be unsafe (with CAs creating such CRLs)
and would be a backwards-incompatible change to rfc5280 and X.509.

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 18 Sep 2012 09:41:21 -0400

Steve,

How about some weasel-wording like "If no other current CRL for the certificate in question can be obtained, the certificate shall be considered revoked.  A CRL is considered current if the current time is before the next update field in the CRL".

Note that Section 6.3 of RFC 5280 does not cover all the cases for revocation.  For example, 6.3 logic ends with certificate status UNDETERMINED in some cases, but the "calling section" in 6.1 does not say what to do with UNDETERMINED.  Another example is 6.3 itself.  In 6.3.3, It says "verify that the current time is before the next update value in the new CRL"  It never says what if it is not, i.e., no CRL is available whose next update is after the current time.

So, I think weasel-wording is ok since lack of revocation information or stale revocation information is not dealt with by 5280 and is left up to the relying party applications.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Monday, September 17, 2012 5:30 PM
To: pkix
Subject: [pkix] 5280bis

I am in favor of discussing how to improve the CRL extension text that we just added.

I am not as concerned about whether we are in perfect alignment with X.509. In general it is preferable to not introduce differences between the IETF and ITU-T standards. But we have had such differences in the past, when there were good reasons. For example, PKIX has always required the next update field to be present, since it's omission was a serious error in the X.509 standard.

I believe that the example provided by indirect CRL entries is the principle motivation to clarify the wording in 5280. The "safe" interpretation is to treat the serial number of the cert in a CRL as being from the set of certs issued by the CA that issued the CRL. Unfortunately, this is also a bad interpretation when the cert serial number is supposed to be associated with a different CA, as indicated by this CRL entry extension.

Anyway, I'd like to see this discussion focus on what appears to be the principle issue, i.e., the merits of playing it safe vs. shooting ones self in the foot, rather than a discussion of whether a rewording will cause 5280 to deviate from the current version of X.509.

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Sep 2012 10:19:30 -0400

Santosh,

I'm comfortable with "undetermined" as the outcome of a CRL check, if 
the WG would rather be
on the side of avoiding unintended revocation (and thus, DoS), vs. a 
"better safe than sorry"
strategy. What I have not seen is a clear indication of preferences in 
this regard, by other
than 3 WG members. Only when we have a clear direction re the policy, 
can we work out the fine
print for 5380bis.

So, let's begin a straw poll today.

1- "better safe than sorry"
2- "better to avoid unintended revocation"
3- don't care

This poll will close on October 1.

Please, just send a reply with a number between 1 and 3. No rationale, 
no tirades, ...

Thanks,

Steve

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 25 Sep 2012 10:24:48 -0400

2

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, September 25, 2012 10:20 AM
To: Santosh Chokhani
Cc: pkix
Subject: Re: [pkix] 5280bis

Santosh,

I'm comfortable with "undetermined" as the outcome of a CRL check, if the WG would rather be on the side of avoiding unintended revocation (and thus, DoS), vs. a "better safe than sorry"
strategy. What I have not seen is a clear indication of preferences in this regard, by other than 3 WG members. Only when we have a clear direction re the policy, can we work out the fine print for 5380bis.

Please, just send a reply with a number between 1 and 3. No rationale, no tirades, ...

Thanks,

Steve

---

From: "Rick Robinson" <[email-masked]>
Date: Tue, 25 Sep 2012 08:40:52 -0600

2

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Santosh Chokhani
Sent: Tuesday, September 25, 2012 8:25 AM
To: Stephen Kent
Cc: pkix
Subject: Re: [pkix] 5280bis

2

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Tuesday, September 25, 2012 10:20 AM
To: Santosh Chokhani
Cc: pkix
Subject: Re: [pkix] 5280bis

Santosh,

I'm comfortable with "undetermined" as the outcome of a CRL check, if the WG
would rather be on the side of avoiding unintended revocation (and thus,
DoS), vs. a "better safe than sorry"
strategy. What I have not seen is a clear indication of preferences in this
regard, by other than 3 WG members. Only when we have a clear direction re
the policy, can we work out the fine print for 5380bis.

Please, just send a reply with a number between 1 and 3. No rationale, no
tirades, ...

Thanks,

Steve

---

From: [email-masked]
Date: Tue, 25 Sep 2012 16:45:39 +0200

Steve,

I don't understand your question.
What is the question in its full context, so that I can reply ?

Denis

De :    Stephen Kent <[email-masked]>
A :     Santosh Chokhani <[email-masked]>
Cc :    pkix <[email-masked]>
Date :  25/09/2012 16:19
Objet : Re: [pkix] 5280bis
Envoyé par :    [email-masked]

Santosh,

Thanks,

Steve

---

From: Piyush Jain <[email-masked]>
Date: Tue, 25 Sep 2012 14:51:00 +0000

Steve,

I think I'm missing the context here.
Is this question around critical unknown CRL entry extensions, unknown critical CRL extensions, or CRls with nextUpdate in the past?

-Piyush

> Stephen Kent
> Sent: Tuesday, September 25, 2012 7:20 AM
> To: Santosh Chokhani
> Cc: pkix
> I'm comfortable with "undetermined" as the outcome of a CRL check, if the
> WG would rather be on the side of avoiding unintended revocation (and
> thus, DoS), vs. a "better safe than sorry"
> regard, by other than 3 WG members. Only when we have a clear direction
> re the policy, can we work out the fine print for 5380bis.
>

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 25 Sep 2012 15:55:42 +0100

On 25/09/2012 15:19, Stephen Kent wrote:
> would rather be
> on the side of avoiding unintended revocation (and thus, DoS), vs. a "better
> safe than sorry"
> regard, by other
> than 3 WG members. Only when we have a clear direction re the policy, can we
> work out the fine
> print for 5380bis.
> 

2

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Sep 2012 08:00:43 -0700

> What is the question in its full context, so that I can reply ? 

+1 (and I don't get to do that with Denis very often!)

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Sep 2012 11:13:00 -0400

> Is this question around critical unknown CRL entry extensions, unknown critical CRL extensions, or CRls with nextUpdate in the past?
A CRL contains a list of cert serial numbers.

Extensions exists that may qualify the scope of the serial numbers, e.g.,
to indicate that a serial number is for a cert issued by a different CA.

The question arises of how an RP should behave if there is a critical 
extension
present that might modify the scope of the serial number, but the RP doesn't
understand the extension.

The choices are to assume that the serial number refers to a cert issued
by the CRL issuer, and thus we treat that cert as revoked, or we can say
that we don't know the scope, and thus we will view any cert with that 
serial
number as having an unknown status, irrespective of the issuer.

The first choice is the "better safe than sorry" approach (#1), while
the second choice maps to #2.

This has nothing to do with stale updates.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Sep 2012 11:13:59 -0400

see my reply to Piyush.

Steve

---

From: [email-masked] (Martin Rex)
Date: Tue, 25 Sep 2012 17:56:42 +0200 (CEST)

2 - "better to avoid unintended revocation"

Stephen Kent wrote:
> Please, just send a reply with a number between 1 and 3.
>

Stephen Kent clarified:
> extension present that might modify the scope of the serial number,
> but the RP doesn't understand the extension.
> 
> serial number as having an unknown status, irrespective of the issuer.
>

---

From: Piyush Jain <[email-masked]>
Date: Tue, 25 Sep 2012 17:16:14 +0000

1 - Better safe than sorry.

---

From: "Jeremy Rowley" <[email-masked]>
Date: Tue, 25 Sep 2012 11:37:14 -0600

1 - Better safe than sorry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Piyush Jain
Sent: Tuesday, September 25, 2012 11:16 AM
To: Stephen Kent; Santosh Chokhani
Cc: pkix
Subject: Re: [pkix] 5280bis

> the WG would rather be on the side of avoiding unintended revocation 
> (and thus, DoS), vs. a "better safe than sorry"
> this regard, by other than 3 WG members. Only when we have a clear 
> direction re the policy, can we work out the fine print for 5380bis.
>

---

From: "Art Allison" <[email-masked]>
Date: Tue, 25 Sep 2012 13:53:14 -0400

2- better to avoid unintended revocation

Art Allison 
Senior Director Advanced Engineering, Technology 
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418
Fax  202 775 4981 
www.nab.org 
Advocacy  Education  Innovation

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 25 Sep 2012 20:53:04 +0200

1- Better safe than sorry

-- 
Erwann.

---

From: [email-masked]
Date: Tue, 25 Sep 2012 21:58:45 +0200

1- better safe than sorry

Iñigo Barreira
Responsable del Área técnica
[email-masked]
945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 25 Sep 2012 18:34:10 -0700

2

> strategy. What I have not seen is a clear indication of preferences in
this

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 25 Sep 2012 23:51:28 -0700

On Sep 25, 2012, at 7:19 AM, Stephen Kent wrote:

> Santosh,
> 
> I'm comfortable with "undetermined" as the outcome of a CRL check, if the WG would rather be
> on the side of avoiding unintended revocation (and thus, DoS), vs. a "better safe than sorry"
> strategy. What I have not seen is a clear indication of preferences in this regard, by other
> than 3 WG members. Only when we have a clear direction re the policy, can we work out the fine
> print for 5380bis.
> 

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: [email-masked]
Date: Thu, 27 Sep 2012 08:18:07 +0200

Steve,

I saw your reply to Piyush which does not solve my concern.

In this WG, we issue RFCs. So we need to say whether some text is 
appropriate or not.

So my questions are:

1) Which text from RFC 5280 do you propose to change ?

2) Then, would you provide the two alternative texts which corresponds to 
option 1 and option 2 ?

Thanks,

Denis

De :    Stephen Kent <[email-masked]>
A :     [email-masked], pkix <[email-masked]>
Date :  25/09/2012 17:57
Objet : Re: [pkix] 5280bis

see my reply to Piyush.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 Sep 2012 03:28:02 -0400

Denis,

I am conducting a poll now, so the question of which text may change, 
and how, is not in
scope for the discussion.

We'll burn that bridge when we come to it.

Steve
-----
On 9/27/12 2:18 AM, [email-masked] wrote:
> 2) Then, would you provide the two alternative texts which corresponds 
> to option 1 and option 2 ?
>
> Thanks,
>
> Denis
>
>
>
> ------------------------------------------------------------------------
>
>
>
> see my reply to Piyush.
>
> Steve
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Sep 2012 08:30:20 -0700

1: "Better safe than sorry"