Subject: [pkix] 5280bis

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Oct 2012 17:45:28 -0400

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.

Steve

---

From: "Peter Yee" <[email-masked]>
Date: Sun, 14 Oct 2012 19:36:53 -0700

Version -10 has been uploaded and the sole change (outside of the
name/dates) is the removal of the contentious text.  Please let me know if
there are any other changes that need to be made.  I'm hoping we're
sufficiently controversy free so that we can move the document forward.

Thanks.
		-Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Thursday, October 11, 2012 2:45 PM
To: pkix
Subject: [pkix] 5280bis

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.

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

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Oct 2012 11:21:26 +0200

This is too late for the poll, but a question came to my mind this week
after an ETSI meeting, so I will just post it.

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?

/Stefan

On 10/15/12 4:36 AM, "Peter Yee" <[email-masked]> wrote:

>the

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 19 Oct 2012 08:04:56 -0700

The few implementations that I've worked do not check for critical entry
extension unless/until
- There is a CRL extension that says that CRL entry extension (IDP with
indirect CRL bit on) may impact the whole CRL. In this case the CRL is just
rejected. I have not seen a single implementation supporting indirect CRLs. 
- A CRL entry matches the certificate in question. At that point the CRL
entry is scanned for unknown critical extensions. If there are any, the
certificate is considered unknown.
So in a way these implementations are not compliant with 5280, but it does
not seem to matter there are no CA deployments out there that create CRLs
with critical CRL entry extensions.

Just to give you a perspective, these implementations are deployed not only
at some of the biggest enterprises (PKI size) but also at a few public CAs.

-Piyush

> Stefan Santesson
> Sent: Friday, October 19, 2012 2:21 AM
> To: Peter Yee; 'Stephen Kent'; 'pkix'
> Subject: Re: [pkix] 5280bis
> 
after
> an ETSI meeting, so I will just post it.
> 
> >name/dates) is the removal of the contentious text.  Please let me know
> >if there are any other changes that need to be made.  I'm hoping we're
> >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.
> >

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 19 Oct 2012 17:28:09 +0200

I suspect that you are right.

In particular on the point that I don't think any of this matters in real
implementations.

But it reinforces my impression that the current text in RFC 5280 simply
represents bad engineering.
That is, information that effects the processing of the complete CRL,
should not be hidden in a CRL entry.
It's begging for problems and will most probably never be correctly
implemented.

So personally I regret that the corrected paragraph was removed. It
represented a lot cleaner software design.

/Stefan