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

[Denis Pinkas <[e-mail]>]

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, [e-mail] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix
>>
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix