Re: Question about the edition of RFC 3280

[Denis Pinkas <[e-mail]>]

Russ,

Thank you for this long-awaited answer.

Shortly speaking, the change that has been made cannot be considered as 
"editorial" and introduces an incompatibility with both RFC 2459 and X.509.

Peter Sylvester raised the following questions:

- Whether this reflects a discussion in the working group for which
   consensus had been achieved.

- how the consensus was achieved.

We can see that this change does not reflect a WG consensus and that the WG 
has been kept ignorant when the change was being made (and that the change 
was being made).

Furthermore, the comment that lead to that change has *not* been posted to 
the WG list. We cannot thus speak of a fair and open process.

See additional comments below.

> Denis:
> 
>> ===================================================================
>>
>> A new Request for Comments is now available in online RFC libraries.
>>
>>         RFC 3280
>>
>>         Title:      Internet X.509 Public Key Infrastructure
>>                     Certificate and Certificate Revocation List (CRL)
>>                     Profile
>>         Author(s):  R. Housley, W. Polk, W. Ford, D. Solo
>>         Status:     Standards Track
>>         Date:       April 2002
>>         Mailbox:    [e-mail], [e-mail],
>>                     [e-mail], [e-mail]
>>         Pages:      129
>>         Characters: 295556
>>         Updates/Obsoletes/SeeAlso:    None
>>
>>         I-D Tag:    draft-ietf-pkix-new-part1-12.txt
>>
>> ====================================================================
>>
>> The text that was draft-ietf-pkix-new-part1-12.txt is the following:
>>
>>       "The digitalSignature bit is asserted when the subject public key
>>       is used with a digital signature mechanism to support security
>>       services other than non-repudiation (bit 1), certificate signing
>>       (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
>>       often used for entity authentication and data origin
>>       authentication with integrity."
>>
>> while the text that is in RFC 3280 is the following:
>>
>>       "The digitalSignature bit is asserted when the subject public key
>>       is used with a digital signature mechanism to support security
>>       services other than certificate signing (bit 5), or CRL signing
>>       (bit 6).  Digital signature mechanisms are often used for entity
>>       authentication and data origin authentication with integrity."
>>
>> I would like to know, how/when such a change happened.
> 
> 
> I do not know why you are asking about a change that happened a year 
> ago, but here is the history.  This took quite a bit of time to pull 
> together, and it involved searching the archives kept by several 
> different individuals.
> 
> During IETF Last Call, the authors received a comment regarding the key 
> usage bits.  We have been unsuccessful in locating this email message, 
> so you will have to live with the personal recollection of the content 
> of this message.  

It is quite strange that such a message has been lost by all the editors 
together. :-|

Unless someone from the WG mailing list remember that he posted this message 
and makes itself known, the reality of the existence of this message will be 
questionable.

Can anyone from the WG identifies himself as being the sender of the message 
that lead to that change ?

> The comment stated that section 4.2.1.3 contained an 
> inconsistency.  The comment pointed to the following text from 
> draft-ietf-pkix-new-part1-12.txt:
> 
>       The digitalSignature bit is asserted when the subject public key
>       is used with a digital signature mechanism to support security
>       services other than non-repudiation (bit 1), certificate signing
>       (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
>       often used for entity authentication and data origin
>       authentication with integrity.
> 
>       The nonRepudiation bit is asserted when the subject public key is
>       used to verify digital signatures used to provide a non-
>       repudiation service which protects against the signing entity
>       falsely denying some action, excluding certificate or CRL signing.
>       In the case of later conflict, a reliable third party may
>       determine the authenticity of the signed data.
> 
>       Further distinctions between the digitalSignature and
>       nonRepudiation bits may be provided in specific certificate
>       policies.
> 
> The crux of the comment was: When the digitalSignature bit is asserted, 
> then the digital signature mechanism supports security services other 
> than non-repudiation.  This means that there is no overlap between these 
> two bit settings.  This is in conflict with the statement that policy 
> can provide further distinction between digitalSignature and 
> nonRepudiation.

When the addition was discussed noone said that additional text neeeded to 
be changed.

If the person that sent the message saw a contradiction, then this issue 
should have at least advertised to the WG.

A simple way to solve this "contradiction" would have been to delete the 
addition.

As far as I am concerned, I interpreted the sentence by the fact that some 
certificate policies may refuse to issue certificates with the two bits set, 
while some others may accept. The exclusivity of bits 1 and 0 is not 
mandated, but is certainly a potentially very dangerous combination.


> In resolving this comment, the authors also considered the vast volumes 
> of messages on the PKIX WG mail list regarding the disputed meaning of 
> these bits.  Recall that the third paragraph was added as a result of 
> that very long discussion.

Since you mention that it was a disputed debate, any change to that section 
should have been brought back to the group.

> The actual changes were made to the document by the RFC Editor, and the 
> request of the authors and concurrence of the Security Area Director.  
> These changes were considered to be clarifications that resolved an 
> internal inconsistency.

I am sorry, but the change is well behind a "clarification" since it 
introduces a major change with the agreed document placed on the web server, 
i.e. version 12. Once a document is placed on the server, only real 
editorial changes can be done. This one cannot fall in this category.

> The following is the note from the authors to the RFC Editor:
> 
>> Date: Wed, 17 Apr 2002 14:57:50 -0400
>> To: [e-mail]
>> From: Russ Housley <[e-mail]>
>> Subject: Re: draft-ietf-pkix-new-part1-12.txt
>> Cc: [e-mail], [e-mail], [e-mail]
>>
>> Dear RFC Editor:
>>
>> Here are the changes that are needed for draft-ietf-pkix-new-part1-12.txt
>>
>> [snip]
>>
>> Section 4.2.1.3, 4th Paragraph: Drop "non-repudiation (bit 1)" from the
>> 1st sentence.  Otherwise it conflicts with the first and last paragraphs
>> of the same section.
>>
>> OLD:
>>
>>    Bits in the KeyUsage type are used as follows:
>>
>>        The digitalSignature bit is asserted when the subject public key
>>        is used with a digital signature mechanism to support security
>>        services other than non-repudiation (bit 1), certificate signing
>>        (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
>>        often used for entity authentication and data origin
>>        authentication with integrity.
>>
>> NEW:
>>
>>     Bits in the KeyUsage type are used as follows:
>>
>>        The digitalSignature bit is asserted when the subject public key
>>        is used with a digital signature mechanism to support security
>>        services other than certificate signing (bit 5), or CRL signing
>>        (bit 6).  Digital signature mechanisms are often used for entity
>>        authentication and data origin authentication with integrity.
>>
>> [snip]
> 
> 
> In response to this request, the RFC Editor contacted the Security Area 
> Directors to confirm that the changes were appropriate.  Jeff Schiller 
> responded with the following message:
> 
>> Date: Wed, 17 Apr 2002 19:37:36 -0400
>> From: "Jeffrey I. Schiller" <[e-mail]>
>> To: [e-mail]
>> Cc: [e-mail], [e-mail], [e-mail]
>> Subject: Re: AD response request: Re: draft-ietf-pkix-new-part1-12.txt
>>
>> I have reviewed the changes and they look fine to me.
>>
>>                         -Jeff
>>
>> On Wed, Apr 17, 2002 at 10:18:22PM +0000, [e-mail] 
>> wrote:
>> > Jeff and Steve,
>> >
>> > Could you please verify that the following changes are okay?  For the
>> > most part, they seem editorial in nature, but we wanted to get an okay
>> > from you guys as there are such a great number of changes.
>> >
>> > Thank you.
>> >
>> > RFC Editor

> Denis, this is the history.  

We cannot change history, but we can now consider how to correct the situation.

> I think you can see that an appropriate comment resolution process was followed. 

I have to disagree with your statement.

 > I am sure you have faced similar comments on documents that you have
 > authored.

Up to now, I have not faced such a situation, and given that experience it 
is very unlikely that I will ever face it.

I am awaiting for proposals from yourself, the co-chairs and/or the Security 
Area Directors on the way to re-establish a backward compatibility with RFC 
2459.

Denis

> Russ