|
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: This illustrates once again that keeping the current text would be the worse of all the solutions.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? 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".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:
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.
If this appeal
is rejected, the text from RFC 5280 will stay as it is,
but it is incorrect. If the document
is sent back the WG, as requested, I believe it would be
appropriate
to ask to the PKIX co-chairs :
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, 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 The relying
party can always try an alternate CRL or
and alternate protocol like OCSP to check out the certificate
of interest.
I am unclear how
local policy can be helpful here.
If there is an unrecognized CRL Entry Extension, the relying
party knows
If the relying
party does not know the issuer
associated with a particular CRL entry, then it does not know
whether that
entry 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. 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: |