Subject: 3280bis: key usage (13)

From: Denis Pinkas <[email-masked]>
Date: Thu, 26 May 2005 11:00:52 +0200

To the list,

The disposition of comments states:

  13) The descriptions of the meanings of the digitalSignature and
      nonRepudiation bits of keyUsage may need to be adjusted based
      on the work in X.509

   The new text in X.509 aligns with the text in RFC 3280.  No changes
   are required to 3280bis.  A comment has been added to the ASN.1 for
   KeyUsage stating that "recent editions of X.509 have renamed
   [the nonRepudiation] bit to contentCommitment"

This statement is untrue.

The text from X.509 has been published in Corrigendum 3 (04/2004)
on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called

ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).

An extract from this text is copied below:

a) digitalSignature: for verifying digital signatures that are used
    with an entity authentication service, a data origin authentication
    service or/and an integrity service;

b) contentCommitment: for verifying digital signatures which are intended
    to signal that the signer is committing to the content being signed.
    The type of commitment the certificate can be used to support may be
    further constrained by the CA, e.g. through a certificate policy.
    The precise type of commitment of the signer e.g. "reviewed and
    approved" or "with the intent to be bound", may be signalled by the
    content being signed, e.g. the signed document itself or some additional
    signed information.

    Since a content commitment signing is considered to be a digitally signed
    transaction, the digitalSignature bit need not be set in the certificate.
    If it is set, it does not affect the level of commitment the signer has
    endowed in the signed content.

    Note that it is not incorrect to refer to this keyUsage bit using the
    identifier nonRepudiation. However, the use of this identifier has been
    deprecated. Regardless of the identifier used, the semantics of this bit
    are as specified in this Directory Specification.

The text from 3280 is copied below:

       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.

       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 text from 3280bis does not align with the ISO-ITU text.
Please align with the the ISO-ITU text.

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 May 2005 14:49:31 +0100

Denis,

 > Please align with the the ISO-ITU text.

Do you mean we should rename the bits and include the
other new x.509 text? The design team were against
doing that.

Is there any (good) reason other than alignment to
make such a change?

Personally, I find the new x.509 text worse, although
it does say: "Note that it is not incorrect to refer to
this keyUsage bit using the identifier nonRepudiation."
So I can argue that we are aligned, just not identical.

But of course, I'm from the non-repudiation is non-sense
camp so I may not be the best judge.

Stephen.

 > This statement is untrue.

The paragraph to which I assume you refer contains 3
statements - it'd be easier to close these threads if
you were more precise. (I think I got what you want
by the end of the mail though...)

PPS: "This statement is untrue."
      Are you from Crete after all? :-)

---

From: Hoyt L Kesterson II <[email-masked]>
Date: Thu, 26 May 2005 12:15:54 -0700

Stephen

I am somewhat dismayed at your reaction to the new text in X.509. I am not going to argue with you here (maybe in a bar the next time we run into each other). However, I do want to mention several points.

1) I initiated the change in text because of the various interpretations by implementors that were resulting in non-interoperable implementations. It was a conversation with a PKIXer at a RSA conference a few years ago that caused me to articulate a private concern.

2) The legal community was very confused. There was even a paper castigating the standard developers for mandating that one could not repudiate an action.

3) There were several meetings held where there was significant participation by people in the IETF PKIX group (as well as lawyers). All agreed there was a problem with the published text. Denis and I argued long and hard over wording but we didn't disagree on the need for new text and its general intent.

4) Russ was concerned that change would cause a problem with existing IETF standards and was not too happy with a change to the name of the bit. That's why I put the line in that you referenced. However, that was to grandfather existing text, not to allow new text to continue using the old term and definitions.

5) It is the definition that is important. I recommend that any new text align with the definition in the approved technical corrigenda against the 4th edition and in the upcoming 5th edition.

    hoyt

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 May 2005 10:58:17 +0100

Hi Hoyt,

Hoyt L Kesterson II wrote:

> Stephen
> 
> I am somewhat dismayed at your reaction to the new text in X.509. 

I'm sorry about that, but I guess I'm just fed up with the
NR bit, though I can understand how people who've worked
hard to try fix it might be dismayed.

(BTW: I once suggested that CAs MUST set this bit randomly
since that was the only way I could see to kill it off
properly. If you can get that into X.509 then I'd be happy
for 3280bis to align:-)

 > I am not going to argue with you here (maybe in a bar the next time
 > we run into each other).

Good idea!

> However, I do want to mention several points.
> 
> 1) I initiated the change in text because of the various interpretations 
 > by implementors that were resulting in non-interoperable
 > implementations. It was a conversation with a PKIXer at a RSA
 > conference a few years ago that caused me to articulate a private
 > concern.

I agree that everything connected with this bit has been
confused and remains so.

> 2) The legal community was very confused. There was even a 
 > paper castigating the standard developers for mandating that
 > one could not repudiate an action.

Maybe the mistake was defining a bit that laywers care about?

> 3) There were several meetings held where there was significant 
 > participation by people in the IETF PKIX group (as well as
 > lawyers). All agreed there was a problem with the published text.
 > Denis and I argued long and hard over wording but we didn't
 > disagree on the need for new text and its general intent.

Fair enough.

> 4) Russ was concerned that change would cause a problem 
 > with existing IETF standards and was not too happy with a
 > change to the name of the bit. That's why I put the line
 > in that you referenced. However, that was to grandfather
 > existing text, not to allow new text to continue using
 > the old term and definitions.

Ok. Here's the real reason not to change: Many people use
ASN.1 compilers which means that names from the ASN.1
module end up being directly used in higher layer code.
Changing the name causes that code not to compile. I'd
say that there's quite a lot of 3280 code in the world
at this stage. So, if the semantics isn't supposed to
have changed (and I assume that is meant to be the
case) then this cost just doesn't seem worthwhile.

> 5) It is the definition that is important. I recommend 
 > that any new text align with the definition in the approved
 > technical corrigenda against the 4th edition and in
 > the upcoming 5th edition.

While I'd rather not see any more text added on this,
(there's been way too much already) I wouldn't have a big
issue with trying to help a reader make sense of the
fact that 3280bis and x.509 name this bit differently.

However text like the sentence below is IMO almost
certain to cause even more confusion:

   The precise type of commitment of the signer e.g. "reviewed
   and approved" or "with the intent to be bound", may be
   signalled by the content being signed, e.g. the signed
   document itself or some additional signed information.

That sounds like the sole purpose of the CC-bit is as
a flag to indicate when some other bits somewhere else
tell you what the CC-bit means.

So in the absence of some better text I think that 3280bis
is better off just saying "NR a.k.a. CC" as it currently
does.

Regards,
Stephen.

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 27 May 2005 12:29:02 +0200

Stephen,

I agree with everything Hoyt said on bit 1.

However, there are two sides for this coin : bit 0 and bit 1.

Both are again copied below:

ISO Corrigendum:

3280bis:

The current text of 3280bis for bit 0 (ds) is incompatible with the ISO
Corrigendum.

As Hoyt already said, any new text should align with the definition in the 
approved technical corrigenda against the 4th edition and in the upcoming 
5th edition.

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 May 2005 13:22:40 +0100

Hi Denis,

I've no problem with aligning the DS bit text although I
wouldn't say that they're incompatible actually. I like
the way 3280 says the DS isn't for certs or CRLs which
ISO doesn't seem to include. Would you like to propose
an aligned paragraph?

I oppose inclusion of new NR/CC text and the name change.

Stephen.

Denis Pinkas wrote:

> As Hoyt already said, any new text should align with the definition in 
> the approved technical corrigenda against the 4th edition and in the 
> upcoming 5th edition.
> 
> Denis
> 
>> Hi Hoyt,
>>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 27 May 2005 14:30:32 +0200

Stephen,

Just before leaving my office in a few minutes for a few days,
here is a new text proposal for the DS bit:

New proposal for 3280bis:

     The digitalSignature bit is asserted when the subject public key
     is used for verifying digital signatures that are used
     with an entity authentication service, a data origin authentication
     service or/and an integrity service. However, it SHALL not be set
     when certificate signing (bit 5) or CRL signing (bit 6) is set.

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 May 2005 13:39:51 +0100

Denis,

Fine by me.

Have a nice trip,
Stephen.

Denis Pinkas wrote:

>>> As Hoyt already said, any new text should align with the definition 
>>> in the approved technical corrigenda against the 4th edition and in

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 28 May 2005 01:16:43 +1200

Denis Pinkas <[email-masked]> writes:

>The digitalSignature bit is asserted when the subject public key is used for
>verifying digital signatures that are used with an entity authentication
>service, a data origin authentication service or/and an integrity service.

Wouldn't it be better to say that it's used for purposes other than CC?  By
saying that DS can only be used for purposes A, B, and C, and CC for purpose
D, what happens if someone wants to mark a key for purpose E?  Since CC seems
to be the more restrictive, it would be better to say that DS is to be used
for everything else.  If not, we'd need a third signature bit to cover the
'other' category that's explicitly excluded from DS and CC.

>However, it SHALL not be set when certificate signing (bit 5) or CRL signing
>(bit 6) is set.

Why not?  The intent of the original text was to say that digitalSignature
doesn't mean you can use the cert for cert/CRL signing, now it says something
completely different, that a cert-signing cert can never be used for any other
purpose.  This wording change would make a number of CAs non-compliant, since
they do use their CA certs for other purposes (don't ask me why, I just see
the things turn up from time to time).  The wording should be something like
"Setting this bit doesn't mean the cert can be used for cert or CRL signing;
for that, you need to set the cert/CRL signing bits".

(I realise this stuff should be obvious to anyone, but there are going to be
 CAs and vendors out there who defend their buggy software by interpreting the
 text as literally as possible, so it had better not contain any loopholes).

Peter.

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 27 May 2005 09:50:51 -0400

Denis,

I do not agree with your proposal for the digitalSignature bit.  Here is 
the current text:

This text merely states that setting the digitalSignature bit, by 
itself, does not authorize relying parties to use the subject public key 
to verify signatures on certificates or CRLs.  It does not prevent a CA 
from setting digitalSignature, keyCertSign, and cRLSign in the same 
certificate.

Imposing this restriction would, for example, prevent a CA from using 
its certificate signing key to also sign OCSP responses.

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 27 May 2005 10:58:32 -0400

I agree with David Cooper.  In addition to David's argument, Dennis's
proposal will also break many known PKI implementation for no security or
interoperability reasons.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Friday, May 27, 2005 9:51 AM
To: Denis Pinkas
Cc: pkix
Subject: Re: 3280bis: key usage (13)

Denis,

Denis Pinkas wrote:

> Stephen,
>
> Just before leaving my office in a few minutes for a few days, here is 
> a new text proposal for the DS bit:
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 May 2005 15:59:39 +0100

Peter,

> 'other' category that's explicitly excluded from DS and CC.

You're kidding, right?

There's a bit (NR/CC) whose meaning has been the subject of
loads and loads of rambling discussion for ages and ages,
and you want to define DS=NOT(NR/CC)? Sounds like a great
way to spread the NR fuzziness around, i.e. a bad idea.

 > Why not?  The intent of the original text was to say that
 > digitalSignature doesn't mean you can use the cert for cert/CRL
 > signing, now it says something completely different, that a
 > cert-signing cert can never be used for any other purpose.  This
 > wording change would make a number of CAs non-compliant, since
 > they do use their CA certs for other purposes (don't ask me why,
 > I just see the things turn up from time to time).  The wording
 > should be something like "Setting this bit doesn't mean the
 > cert can be used for cert or CRL signing; for that, you need
 > to set the cert/CRL signing bits".

You're right there (as is David C.) So we should replace Denis'
last sentence with something like yours, giving maybe:

     The digitalSignature bit is asserted when the subject public key
     is used for verifying digital signatures that are used
     with an entity authentication service, a data origin authentication
     service or/and an integrity service. Note that a certificate
     with only the digitalSignature bit set MUST NOT be used for
     verifying certificate or CRL signatures.

And the certificate and CRL signing bits are described elsewhere.

Stephen.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 28 May 2005 03:16:03 +1200

Stephen Farrell <[email-masked]> writes:

>There's a bit (NR/CC) whose meaning has been the subject of loads and loads
>of rambling discussion for ages and ages, and you want to define DS=
>NOT(NR/CC)? Sounds like a great way to spread the NR fuzziness around, i.e. a
>bad idea.

Oh was that what all that was about?  I'd gone off to reorganise my sock
drawer and sort my packets of alphabet soup after the first 800 or so messages
went by, so I probably missed some bits.

The motivation for the comment was that we've just gone through the
keyEncipherment vs. dataEncipherment debate where no-one's quite sure which
bits to set for what occasion, and now in an attempt to fix the equally-
problematic DS vs. NR we're creating a similar problem: what do you do in
situations where neither the DS nor CC/NR bits fit?  I don't really care how
the bits are defined, as long as it doesn't end up creating un-uses that can't
be clearly signified with either DS or CC/NR.  Without this, we'll get another
situation like the dataEncipherment one where something doesn't fall easily
into either choice, so users and CAs claim that their choice of DS or CC
applies, whatever happens to coincide with what their software does.

>     verifying certificate or CRL signatures.

Sounds good to me.

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 May 2005 16:25:37 +0100

Peter,

> problematic DS vs. NR we're creating a similar problem: [...]

Fair enough. Problem is we'll apparently never get agreement
on what NR/CC means:-(

>>    verifying certificate or CRL signatures.

Cool. Let's see what happens when Denis get back so,
Stephen.

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 27 May 2005 14:36:53 -0400

David Chadwick and I argued within X.509 that if there are going to be 
two (or four) bits,
then those bits should specify non-overlapping purposes (i.e.  DS for 
purpose A,
NR/CC/?? for purpose B, Cert-S for purpose C and CRL-S for purpose D, where
A, B, C and D are mutually exclusive and collectively exhaustive).  The 
suggestion
at the time was to consider ephemeral signatures (entity authentication 
w/ liveness)
to be purpose A, and persistent signatures (data origin authentication / 
integrity with no
implication of presence/liveness) to be purpose B.

That view was roundly rejected by all present, who subscribed to 
Stefan's theory of
contagious fuzziness.  So given that the decision has been made to 
create a fuzzy
non-implementable definition for NR/CC, I believe PKIX should adopt 
Stephen's
suggestion that CA's MUST set this bit to a random value.

Dave

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 30 May 2005 21:19:48 +1200

"David P. Kemp" <[email-masked]> writes:

>The suggestion at the time was to consider ephemeral signatures (entity
>authentication w/ liveness) to be purpose A, and persistent signatures (data
>origin authentication / integrity with no implication of presence/liveness)
>to be purpose B. That view was roundly rejected by all present, who
>subscribed to Stefan's theory of contagious fuzziness.

Uhh, just for the record, I've always supported this interpretation, it's
simple, straightforward, and easy to understand.  From private discussions in
the past that there are others here who support this as well, but they tend to
fall into the class of PKI app developers/implementors, who have mostly
abandoned this list or use it purely in read-only mode.

Peter.