Re: Question about the edition of RFC 3280

[Russ Housley <[e-mail]>]

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.  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.

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.

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.

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.  I think you can see that an appropriate 
comment resolution process was followed.  I am sure you have faced similar 
comments on documents that you have authored.

Russ