ietf
[Top] [All Lists]

RE: [pkix] Last Call: <draft-ietf-pkix-rfc5280-clarifications-08.txt>

2012-10-19 11:30:00
To the IESG,

I am making an appeal to the IESG from the decision of Steve Kent one of the co-chairs of the PKIX WG to send back the document draft-ietf-pkix-rfc5280-clarifications-10.txt to the IESG.

This decision has not even been taken in agreement with the other PKIX co-chair Stefan Santesson, since he posted
a message on October 19 to the PKIX list saying:

   The current text requires me to reject a CRL as source of revocation
   information if ANY entry includes an unrecognised extension.
   So thinking as an implementer, I just wander how this works in practice.

   Consider I have a 100 MB CRL.
   I then have to go through each entry and determine if any of them have an
   unrecognised extension before I use it.

   Just going to the entry of interest is not enough, since another entry may
   have an unrecognised extension.

   Is this how implementations work today?

This illustrates once again that keeping the current text would be the worse of all the solutions.
*
**I am asking the IESG to send back the document (update to RFC 5280) to the WG.*

When the original last call was placed I sent the following argument:

   A discussion has just started yesterday on the PKIX mailing list
   about an "Errata in section 5.3 from RFC 5280".

   At this time it can clearly be seen that RFC 5280 is NOT compatible
   with X.509 for the processing of
   crlEntryExtensions, whereas RFC 5280 is supposed to be a *profile*
   of X.509.

   For that reason, I ask the IESG to suspend its decision until the
   issue about crlEntryExtensions is clarified
   one way or another, since this point now needs to be clarified and
   will impact a document whose goal is precisely
   to clarify RFC 5280.

My request has been accepted and the WG has worked in order to attempt to solve the issue.

Several people tried to propose text to fix the current text, while some others were providing arguments to say that the text was not "good enough"
but did not proposed an alternative text proposal.

The last exchanges, when attempting to correct the processing of CRL entry extensions in RFC 5280, are the following:

On October 5, Denis Pinkas (i.e. myself) made a new strawman proposal, using a text proposed by Steve Kent.

On October 9, 2012, Russ Housley replied to Denis Pinkas saying that he had arguments against this text.

On October 11, without leaving me the time to reply to Russ, Steve Kent asked Peter Yee to remove the Section 4 text from 5280bis and publish version -10.

In my opinion, Russ Housley has not spent sufficient time to read my proposal since his arguments did not take into consideration my proposed text.

Usually a two weeks interval is given by the chairs before making a decision. In this case, it has been *two days*, without any warning. I believe this is unfair.

The two co-chairs should have remembered to the WG participants (including Russ Housley as PKIX WG participant) how to address strawman proposals: everyone is allowed to critize a strawman proposal, as long as he provides technical arguments for what he believes is incorrect, and also attempts to build
a new strawman proposal using as much as possible the previous one.

This is one of the explanations (but not the single one) why the PKIX WG is now unable to reach consensus. The co-chairs should act as facilitators. They have been too often taking advantage of their "chair hat" while defending their own arguments or their own text.

If this appeal is rejected, the text from RFC 5280 will stay as it is, but it is incorrect. Sharon Boeyen, the editor X.509, confirmed it was incorrect on the PKIX list on August 28, 2012.

If the document is sent back the WG, as requested, I believe it would be appropriate to ask to the PKIX co-chairs :
   (1) to manage the PKIX WG "more appropriately",
(2) to remember to all the WG participants how to address strawman proposals, and (3) to avoid taking advantage of their "chair hat" while defending their own arguments or their own text.


I believe that the PKIX WG can agree on a "minimum text" shortly.
Having a polished text is even possible, but only if the WG participants are clearly instructed how to deal
with strawman proposals.


All of this is only in the interest of publishing RFCs with a correct content.

Denis Pinkas

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

The facts (in reverse order):

3) On October 11, 2012, without any pre warning, Steve Kent, one of the co-chairs of the PKIX WG said :

"The PKIX list has not demonstrated consensus for the CRL entry extension text I suggested, or any other,
since Russ sent his message on this topic on 10/3, over a week ago.

Consistent with Russ's direction, I have asked Peter Yee to remove the Section 4 text from 5280bis and publish version -10.

I have begun preparation of the IESG report for the redacted version of the doc".

2) On October 9, 2012, Russ Housley replied to Denis Pinkas:

" do not support this alternate text. If there is an unrecognized CRL Entry Extension, then the replying party cannot know whether the entry applies to a particular certificate or not. Certificates are identified by an issuer and serial number. An unrecognized CRL Entry Extension can change the issuer portion of the tuple.

The relying party can always try an alternate CRL or and alternate protocol like OCSP to check out the certificate of interest.
This would be true for any type of CRL validation trouble.

I am unclear how local policy can be helpful here. If there is an unrecognized CRL Entry Extension, the relying party knows
that it cannot use the entry.

If the relying party does not know the issuer associated with a particular CRL entry, then it does not know whether that entry is associated with the certificate of interest or not. Given this situation, I think that the appropriate action is not to treat the certificate as revoked; instead, the CRL is providing no useful information to make such a decision".

1) On October 5, 2012, Denis replied to Russ:

You said:

" Steve put forward some alternate text, but it does not seem to have any more consensus than the text in the current I-D.
Can Steve's text be changed in a way that gets us to consensus? "

Here is a new proposal for changing Steve's text.

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

   The CRL entry extensions defined by ISO/IEC, ITU-T, and ANSI X9

   for X.509 v2 CRLs provide methods for associating additional

   attributes with CRL entries [X.509] [X9.55].   The X.509 v2 CRL

   format also allows communities to define private CRL entry

   extensions to carry information unique to those communities.

   Each extension in a CRLentry may be designated as critical or

   non-critical.   A critical extension in the crlEntryExtensions

   field of an entry SHALL affect only the certificate identified

   in that entry, unless there is a related critical extension in

   the crlExtensions field that advertises a special treatment for

   it.

   If a CRL contains a critical CRL entry extension that the

   application cannot process, then the relying party SHOULD use,

   if possible, other sources of certificate revocation status

   (e.g. OCSP) to accurately the revocation status of the

   certificate identified in that CRLEntry.

   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 SHOULD consider that the revocation status of the

   certificate is revoked.

   Note: In the last case, the relying party may treat a valid

         certificate as being revoked.   However, since most CAs are

         currently using large random certificate serial numbers,

         a collision between such numbers is rather unlikely.

         So it is more likely that the certificate serial number

         identified in the CRLentry relates to the right CA.

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

The Note above could be transformed and placed in the security considerations 
section.

It is taking care of a situation that is likely to happen one out of a zillion 
of zillion cases.

It is one of the reasons why I have not kept the "dramatic" sentence from 
Steve's proposal:

"the relying party is faced with a difficult choice".

It seems that the PKIX WG is faced with a difficult choice.   I see three ways 
we could go regarding the update to Section 5.3 of RFC 5280.

(1) Stick with the text in RFC 5280.   At one point in time, there was 
consensus for it.   Ignoring a CRL with an unrecognized CRL Entry Extension
is not aligned with the most recent version of X.509, but it is a safe thing to 
do.

(2) Build consensus for the text in the current I-D.   We have been working 
toward that for several weeks, and we are not making progress.

(3) Build consensus around some alternate text.   Steve put forward some 
alternate text, but it does not seem to have any more consensus
than the text in the current I-D.   Can Steve's text be changed in a way that 
gets us to consensus?   So far, I have seen two major concerns raised that need 
to be resolved if this is the way forward.


Denis


So that nobody is surprised:

I've placed this draft on the 10/25 IESG telechat. The -08 version and the -10 version are technically identical. -08 went through IETF LC so I'm not planning on issuing another IETF LC for -10.

spt

On 10/14/12 10:34 PM, internet-drafts(_at_)ietf(_dot_)org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

Title : Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
    Author(s)       : Peter E. Yee
    Filename        : draft-ietf-pkix-rfc5280-clarifications-10.txt
    Pages           : 7
    Date            : 2012-10-14

Abstract:
    This document updates RFC 5280, the Internet X.509 Public Key
    Infrastructure Certificate and Certificate Revocation List (CRL)
    Profile.  This document changes the set of acceptable encoding
    methods for the explicitText field of the user notice policy
    qualifier and clarifies the rules for converting internationalized
    domain name labels to ASCII.  This document also provides some
clarifications on the use of self-signed certificates, trust anchors,
    and some updated security considerations.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pkix-rfc5280-clarifications-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc5280-clarifications-10


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
pkix mailing list
pkix(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
pkix(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/pkix

<Prev in Thread] Current Thread [Next in Thread>
  • RE: [pkix] Last Call: <draft-ietf-pkix-rfc5280-clarifications-08.txt>, Denis Pinkas <=