Subject: About RFC 3280bis

From: Denis Pinkas <[email-masked]>
Date: Thu, 24 Feb 2005 15:53:11 +0100

Paul Hoffman said on the list on November 8:

"Instead of starting rfc3280bis, start a draft called something like
"rfc3280-changes". Have that draft be short, and contain *only*
changes to 3280. Only after there is consensus on the -changes draft
should you roll the changes in.

No one reads all of 3280 these days, so expecting people to search
through rfc3280bis for different sections is not reasonable".

I was fully agreeing with him and since I saw no neagtive response from the 
co-editors, I thought this was granted.

Then what happened ? Exactly the opposite !

What is the PKIX mailing list for, if the co-editors ignore such messages 
from the list ?

Can we finally have these rfc3280-changes, the list of comments received and 
their proposed resolution, BEFORE we can start reading the new draft ?

Denis

-------- Original Message --------
Subject: Re: Suggestion for revising RFC 3280
Date: Mon, 08 Nov 2004 13:42:12 -0500
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: Paul Hoffman / VPNC <[email-masked]>
CC: [email-masked]
References: <p06110406bda564ea5155@[10.20.30.249]>

Or at least have a paragraph that gets removed prior to RFC publication
to tell everybody where changes were made.

spt

Paul Hoffman / VPNC wrote:

 >
 > Instead of starting rfc3280bis, start a draft called something like
 > "rfc3280-changes". Have that draft be short, and contain *only*
 > changes to 3280. Only after there is consensus on the -changes draft
 > should you roll the changes in.
 >
 > No one reads all of 3280 these days, so expecting people to search
 > through rfc3280bis for different sections is not reasonable.
 >
 > --Paul Hoffman, Director
 > --VPN Consortium
 >
 >

---

From: [email-masked]
Date: Fri, 25 Feb 2005 09:44:37 -0500

I certainly agree that no one has the time to read all of 3280bis these days, 
and that it is important to provide the set of changes in a straightforward 
manner.  However, it was very difficult to convey the complete context of the 
proposed changes without showing how they would impact the current text.   
Describing the changes out of context and rolling them in later would surely 
result in repetitive debates, and I personally don't see the value in arguing 
every issue twice.  To ensure that the complete impact of all changes were 
accurately conveyed, we felt the need to create a 3280bis draft.

To facilitate an efficient review by WG members that are already familiar with 
3280, the editor also has provided an html diff file that shows all changes 
from 3280 to 3280bis. As noted earlier on list, this file is available at

http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html

The html diff file clearly identifies every change (deletions are in red and 
strikethrough, insertions are in green) so no one should have to read the 
entire document or spend cycles figuring out which sections were, or were not, 
modified.

Tim Polk

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Feb 2005 19:24:04 +0000

Tim,

I totally agree!

And since I hadn't done it since -00 was posted, I just
did a quick flick through that html and it took about 30
minutes, start to finish. I didn't read all the changes, but
I think I'd have a reasonable chance of spotting a red flag.
If enough people do that, then I think we can be fairly
confident that the changes are sound, and that we've
improved on 3280.

(And btw - nice work from David, that's some size of a
document to be editing!)

I did spot one possible future change - the serial numbers
of the sample certificates are small (decimal 17,18,256). One
of the suggestions I've seen made for handling potential
hashing weaknesses was to prepend some randomness to those.
*If* (and I don't believe we yet know...I certainly don't) this
is sound guidance then we could reflect it in the samples (and
I guess also the security considerations). Something to think
about for later maybe. Actually, since large serial numbers
are pretty common, having at least one sample with a long
serial number would seem like a good idea in any case.

Stephen.

---

From: Dave Engberg <[email-masked]>
Date: Fri, 25 Feb 2005 18:31:34 -0500

Artificially large serial numbers create some negative performance implications.  The CRLs produced by CAs (RSA, VeriSign, MS) that overload their serial numbers are frequently 50% larger than those who issue low, sequential (aka "serial") numbers (Netscape, UniCert, etc.).  This can translate into extra minutes of waiting every day for users in large PKIs.  If the US DoD followed this recommendation, their CRLs would increase by more than 20MB.

While this serial number overloading is syntactically permitted under the spec, I don't think the RFC needs to encourage this behavior unless there's absolutely no alternative to prevent an imminent SHA-1 meltdown.  I'd prefer to see a SHA-1 solution that generalized to all of the other signatures people use (CRLs, documents, emails, OCSP, etc.).

From: Stephen Farrell
Sent: Fri 2/25/2005 2:24 PM
To: [email-masked]
Cc: pkix
Subject: Re: About RFC 3280bis

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 28 Feb 2005 10:39:42 +0100

Tim,

> entire document or spend cycles figuring out which sections were, or were not, 

This still does not solve the concern.

We need a short document that we can print to review in the train or in the 
plane. I cannot handle a 100 pages document.

Please save our trees (since trees are transformed into paper).

  .. but more important, what we need is a summary of all the change 
requests and, even more important, how they have been addressed.

A change document will not mention the comments that have been discarded.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 28 Feb 2005 16:59:19 +0100

Dave,

No problem. I will wait.

Denis

> Denis,
> 
> Here is what Tim said when he first announced that 3280bis-00 was 
> available:
> 
>  > David has also created an html diff file that shows all changes from 
> 3280 to 3280bis.
>  >
>  > 
>  > He has not had time to pull together a "disposition of comments" 
> email, since I have
>  > him triple booked at the moment.   (In particular, he is working on 
> SCVP as well.)
>  > He will try to get that to the list before the meeting, but the diff 
> file makes it very
>  > easy to identify the changes that have been made.
> 
> I will be creating the "disposition of comments" that you want to see, 
> but I have other projects that are of higher priority that must be 
> completed first.  The disposition of comments will have to wait until I 
> have time.
> 
> For those who want to know how 3280bis-00 differs from 3280, the diff 
> file is the best place to look since it highlights every change, even 
> ones that are too minor to mention in a "disposition of comments" 
> document.  If you don't want to look at the diff file and only want to 
> read the "disposition of comments" document, that's fine.  But, you will 
> have to wait until I have time to write it.
> 
> Dave
> 
> Denis Pinkas wrote:
> 
>> Tim,
>>
>>> I certainly agree that no one has the time to read all of 3280bis 
>>> these days, and that it is important to provide the set of changes in 
>>> a straightforward manner.  However, it was very difficult to convey 
>>> the complete context of the proposed changes without showing how they 
>>> would impact the current text.   Describing the changes out of 
>>> context and rolling them in later would surely result in repetitive 
>>> debates, and I personally don't see the value in arguing every issue 
>>> twice.  To ensure that the complete impact of all changes were 
>>> To facilitate an efficient review by WG members that are already 
>>> familiar with 3280, the editor also has provided an html diff file 
>>> that shows all changes from 3280 to 3280bis. As noted earlier on 
>>> list, this file is available at
>>>
>>> The html diff file clearly identifies every change (deletions are in 
>>> red and strikethrough, insertions are in green) so no one should have 
>>> to read the entire document or spend cycles figuring out which 
>>> sections were, or were not, modified.
>>
>>
>>
>> We need a short document that we can print to review in the train or 
>> in the plane. I cannot handle a 100 pages document.
>>

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 28 Feb 2005 10:52:29 -0500

Denis,

3280 to 3280bis.
email, since I have
SCVP as well.)
file makes it very

Dave