Key usage bits 0 and 1

[Denis Pinkas <[e-mail]>]

To Tim Polk and the WG,

Sorry, this is a long e-mail.

On February 27, 2003, I sent the following message to the co-chairs:

****************************************************************************

Dear co-chairs,

In the light of a Defect Report (n° 299) addressed by ISO SC 6 in London,
I have noticed that a MAJOR change has been done between RFC 2459 and
RFC 3280 about the interpretation of the DS and the NR bits.

As far as I remember, I do not remember that this point has ever been
discussed or mentioned on the mailing list.

I will thus appreciate that you confirm this or point me about some e-mail 
exchanges where this point has been presented, explained and debated. 
Otherwise, to a summary of the changes that explains that point.

Thanks,

Denis

****************************************************************************

On the same day I received a response from Tim Polk:

****************************************************************************

Denis,

[Tim] I am sure it was discussed on the list.  I do not know when; it was 
some time ago.  I believe that change occurred early in son-of-2459.

[Denis] No. I still have most versions. The same text (identical to RFC 
2459) was present from version new-part1-00.doc till version 
new-part1-12.doc, this means between 29 October 1999 and 25 January 2002, 
i.e. during 15 months.

Then the change occured when the document was split into two parts and 
became new-part1-asn1-00.doc on 25 April 2002.

So if you want to look for discussions it may only be between January 2002 
and April 2002. I looked that time frame and there is not a single message 
on that topic.

I remember that we got the message: "no change" except a clean split between 
algorithms and the rest of the document.

So awaiting your own searches ... (...)

[Tim] (...) I cannot do any research on it today.  I will try to identify 
the version of the I-D where the change occurred and the discussion next 
week.  With a little luck, I will send you the reference(s) Tuesday or 
Wednesday.

If you need faster action, the messages should appear in the email archive. 
  That is a lot of mail to look through, though.

****************************************************************************

Then on March 12, 2003 I sent the following e-mail:

****************************************************************************

Dear co-chairs,

On Februray 27, I sent the following message to you:

==========================================================================
In the light of a Defect Report (n° 299) addressed by ISO SC 6 in London,
I have noticed that a MAJOR change has been done between RFC 2459 and
RFC 3280 about the interpretation of the DS and the NR bits.

As far as I remember, I do not remember that this point has ever been 
discussed or mentioned on the mailing list.

I will thus appreciate that you confirm this or point me about some e-mail 
exchanges where this point has been presented, explained and debated. 
Otherwise, to a summary of the changes that explains that point.
==========================================================================

On March 5, I send a remainder to both of you.

On March 11, I sent a second remainder to both of you.

I have received no response at all, since then.

This matter is very important for me, and thus I am awaiting a response 
BEFORE the PKIX meeting. This matter is also related to the proposed 
revision of RFC 3039, for which I am not convinced that a revision is needed.

This time I am copying Russ, as a co-editor of RFC 3280.
He might be able to provide a response.

I am also copying the two Security Area Directors.

Regards,

Denis

****************************************************************************

On May 15, 2002 I sent the following message to the list:

****************************************************************************

After taking a few days off, I have analyzed the storm of the e-mail
exchanges on that topic.

The core of the problem is that some people, by claiming requesting some
"clarifications" on these two bits, would like to change their semantics.

:-(

The roadmap provides a good summary of what happened in the past:

    (...) many discussions were needed to arrive at
    a common agreement on the meaning of the digitalSignature (DS bit)
    and nonRepudiation (NR bit) bits and when they should be set. The
    group quickly realized that key usage extension mixes services and
    mechanisms. The DS bit indicates a mechanism - a public key used to
    verify a digital signature. The NR bit indicates a service - a public
    key used to verify a digital signature and to provide a non-
    repudiation service. When trying to indicate when each bit should be
    indicated arguments were based on:

    The lifetime of the object being singed. Some felt that the DS bit
    should be set when the certificate is used to sign ephemeral objects
    (e.g., bind tokens) while the NR bit should be set for things that
    are survive longer (e.g., documents). Of course, the problem with
    this distinction to determine how long is the time period for
    ephemeral?

    A conscious act taken by the signer. Many felt that the NR bit should
    be set only when the subject has expressly acknowledged that they
    want to use the private key to sign an object. Signing a document say
    where there is a conscious decision by the subject would be
    appropriate for the key usage extension to contain NR, but when the
    key is used for authentication purposes, which can occur
    automatically and more frequently, the DS bit is more appropriate.

    The discussion also concluded that since some authentication schemes
    occur automatically, that the DS bit and NR bit should never be set
    together in the same certificate. Some agreed to the differentiation
    of the bits based on the time, but did not agree that the two could
    not be in the same key usage extension.

    The procedures followed by the CA. Some felt that NR bit was kind of
    'quality mark' indicating to the verifier that the verifier could be
    assured that the CA is implementing appropriate procedures for
    checking the subject's identity, performing certificate archival,
    etc. Other felt that it was not entirely the CAs job and that some
    other entity must be involved.

    In the end the WG agreed to a few things:

    - Provision of the service of non-repudiation requires more than a
      single bit set in a PKC. It requires an entire infrastructure of
      components to preserve for some period of time the keys, PKCs,
      revocation status, signed material, etc., as well as a trusted
      source of time. However, the nonRepudiation key usage bit is
      provided as an indicator that such keys could be used as a
      component of a system providing a non-repudiation service.

    - The certificate policy is the appropriate place to indicate the
      permitted combinations of key usages. That is, a policy may
      indicate that the DS and NR bits can not be set in the same
      certificate while another may say that the DS and NR bits can be
      set in the same certificate.

    [2459bis] includes new text indicating the above agreements.

In addition to these explanations I would like to quickly reply to Sharon to
say her that I disagree (as others) when she says that the only meaning of
the NR bit is to say that the CA has no knowledge of the value of the
private key. This would rule out CAs generating key pairs and would not be
backward compatible with the current meaning.

Now let us attempt to CLARIFY the meaning.

David Kemp offered good explanations on these two bits:

DS bit: the key is used to sign data, nonces or challenges that can be
verified in real-time (entity authentication and data origin authentication
services).

NR bit: the key is used to sign data that can be verified at a later time
(non–repudiation service).

I would offer these additional explanations:

When the DS bit (bit 0) is set, this means that the private key MAY have
been used in an environment that is not fully controlled by the private key
holder. In practice, this means that private keys related to certificates
that have the DS bit set, will be used for entity authentication (e.g.
signing challenges or nonces) or for data origin authentication (signing
data that has not necessarily been reviewed).

Since the environment is not fully controlled by the private key holder, the
private key holder COULD deny that his key was used to sign a transaction,
because he could claim that he was believing that his private key was used
in an authentication process.

Some authorities (like CRL Issuers) can sign by using a key related to a
certificate that only has the DS bit set because they always chose what they
sign and will never use that same key in an authentication exchange.

When the NR bit (bit 1) is set, this means that the private key holder will
only use its private key in an environment that he can control and which
allows him to be confident of the data that is being effectively signed.

The signer cannot claim that he was believing that his private key was
simply used in an authentication process that he could not control.

Denis

****************************************************************************
Now, I did a search in my archives and I have a file named: 
<draft-ietf-pkix-new-part1-12.txt> from January 2002.
It was recorded on January 25, 2002. It has the following text in it:

       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.

I have found an e-mail from the RFC editor dated from May 10, 2002:

That e-mail says:

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

However, the file named draft-ietf-pkix-new-part1-12.txt
is faily different from draft-ietf-pkix-new-part1-12.txt
since the text above has been changed in the following way:

       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.


This is quite strange that two texts with the same name have different 
contents. Maybe the rfc-editor couild explain ?

****************************************************************************

I wanted to inform the list that I am still awaiting a response from Tim, as 
co-editor of RFC 3280 and as co-chair of the PKIX WG (the responses may be 
different).

For the time being, RFC 3280 is NOT backward compatible with RFC 2459 and is 
not compatible either with X.509.

I would like that point to be mentioned at the next PKIX WG meeting.

Regards,

Denis