Subject: RE: 3280bis: key usage (13)

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 27 May 2005 13:06:07 +0100

Speaking as implementer and not design team member, I can live with both
texts since they allow me to do the same thing.

It allows my low level application to add a digital signature supported
by the digital signature bit, where the intention of that application is
to add integrity and origin authentication, while the use of the
signature in practice (higher layers) ends up being used as evidence of
some kind of commitment.

Example. An e-mail application adds an arbitrary signature supported by
the DS bit, while the body of the text reads "Through the digital
signature on this e-mail I commit to....). This is now a perfectly valid
scenario according to both texts.

The real defect that was fixed was that the digital signature bit said
that it was for purposes "other" than NR. That is now gone in both
standards.

I agree to Stephen's rationale to keep the name nonRepudiation. It is
not worth the cost to change the name. Stephen's point here was missing
in the X.509 discussions of a name change.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Denis Pinkas
> Sent: den 27 maj 2005 12:29
> To: Stephen Farrell
> Cc: Hoyt L Kesterson II; pkix
> Subject: Re: 3280bis: key usage (13)
> 
> 
> 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:
> 
>      a) digitalSignature: for verifying digital signatures that are
used
>         with an entity authentication service, a data origin
> authentication
>         service or/and an integrity service;
> 
> 3280bis:
> 
>      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 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
> 
> > 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.
> >
> >>
> >> At 14:49 +0100 5/26/05, Stephen Farrell wrote:
> >>
> >>> 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.
> >>>
> >>> PS: A quibble:
> >>>
> >>>
> >>>>  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 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? :-)
> >>>
> >>>
> >>>
> >>>
> >>> Denis Pinkas wrote:
> >>>
> >>>
> >>>> 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: "Stefan Santesson" <[email-masked]>
Date: Fri, 27 May 2005 16:13:33 +0100

Agree with David.

We need to preserve the old logic in this regard.

Stefan Santesson

> On Behalf Of David A. Cooper
> Sent: den 27 maj 2005 15:51
> To: Denis Pinkas
> Cc: pkix
> 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.
> 
> 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:
> >
> > New proposal for 3280bis:
> >
> >     is used for verifying digital signatures that are used
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: "Stefan Santesson" <[email-masked]>
Date: Fri, 27 May 2005 17:48:28 +0100

The problem is partly to understand what NR/CC is but the real issue why
they can be mutually exclusive is that they define properties of
different abstraction layers.

Applications on the message layer only understand signing within the
concept of data origin authentication and content integrity, they have
no clue whether the signature they process is going to be used for CC/NR
or not.

Example: e-mail client with S/MIME signing will never know the purpose
of signing.

Application on the higher application layers may however know exactly
why you are signing. E.g. web service enabling you to pay an invoice.
This application will know whether the purpose is CC/NR and can pick the
appropriate cert.

So in summary, if you define DS = all signing except CC/NR, they you
confuse all lower layer applications operating on the message layer who
don't have a clue whether their signatures are being used for CC/NR in
any higher layer context.

To the text proposed by Stephen:

It is not quite correct. That text forbids cert and CRL validation when
only DS is set, which is close bon not exactly right. E.g. it does not
prevent Cert and CRL validation when DS+NR/CC are set. I think you need
to move closer to the original RFC 3280 def.

Stefan Santesson

> On Behalf Of Stephen Farrell
> Sent: den 27 maj 2005 17:26
> To: Peter Gutmann
> Cc: [email-masked]; [email-masked]
> Peter,
> > 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: [...]
> 
> Fair enough. Problem is we'll apparently never get agreement
> on what NR/CC means:-(
> 
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.
> >
> > Sounds good to me.
> 
> Cool. Let's see what happens when Denis get back so,
> Stephen.
>