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

From: Denis Pinkas <[email-masked]>
Date: Thu, 02 Jun 2005 11:05:14 +0200

(text deleted)

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

>> Sounds good to me.

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

This is fine with me. This solves the DS issue.
We still need to solve the NR/CC bit issue.

Denis

> Stephen.

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 3 Jun 2005 12:31:28 +0100

I think my proposal was more expressive but I can live with both.

I'm fine as long as the text expresses this message in a way that is
sufficiently clear. I'm sure David can make something good out of these
proposals.

/Stefan

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: den 3 juni 2005 12:09
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: 3280bis: key usage (13)
> 
> Stefan,
> 
> > Just a nit maybe:
> > The following is not untrue but not really what we mean.
> 
> >>>>   Note that a certificate
> > For example: Can you use a certificate with DS + NR to validate
> > signatures on certificates? (it has not DS ONLY set).
> 
> > I think what we do want to say is something like:
> 
> > "Note that verification of CRL and certificate signatures is
explicitly
> > excluded from the definition of the digitalSignature bit. These key
> > usage purposes are defined separately by bit 5 and 6."
> 
> On the long paved road leading to further improvements, why not say:
> 
> "Note that the verification of certificate signatures and CRL
signatures
> is only governed by key usage purposes defined by bits 5 and 6
> respectively".
> 
> Denis
> 
> > /Stefan
> >
> >
> >
> >>-----Original Message-----
> >>From: [email-masked]
> >
> > [mailto:[email-masked]]
> >
> >>On Behalf Of Denis Pinkas
> >>Sent: den 2 juni 2005 11:05
> >>To: Stephen Farrell
> >>Cc: Peter Gutmann; [email-masked]
> >>Subject: Re: 3280bis: key usage (13)
> >>
> >>
> >>
> >>(text deleted)
> >>
> >>
> >>>>>   The digitalSignature bit is asserted when the subject public
> >>>>
> > key
> >
> >>>>>   with an entity authentication service, a data origin
> >>>>
> > authentication
> >

---

From: "Kazin, Joel" <[email-masked]>
Date: Fri, 3 Jun 2005 07:52:26 -0500

At 02:53 AM 6/3/2005 -0500, Denis Pinkas wrote:

To the list, 

We still need a text for bit 1. 

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: 

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. 

This is better said as "the signer has granted to 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. 

I had some face to face discussions with Stefan and we looked for a 
compromise (which means making all parties equally unhappy). He argued that 
as far as the ASN.1 is concerned we should keep the current structure that
is : 

      nonRepudiation          (1), 

The reason is that some software directly use the name of the field for 
display. So the idea would be to keep the current ASN.1 but to mention in a 
note that it would also be legitimate to use the ISO ASN.1, which is : 

      contentCommitment       (1), 

so we would have : 

       KeyUsage ::= BIT STRING { 
            digitalSignature        (0), 
            nonRepudiation          (1), 
    -- this field may also be called contentCommitment 
    -- as per ISO/IEC 9594-8: 2000 / Corrigendum 3 : 2004 
    -- and ITU-T Rec. X.509 (2000) / Corrigendum 3 (04/2004) 
            keyEncipherment         (2), 

The proposal is then to take the text from Corrigendum 3 and provide a link 
with the term non repudiation (which is the most difficult part of the 
exercice). See the third paragraph below which is a strawman. 

I would propose the following text for 3280bis: 

    The nonRepudiation bit is asserted for verifying digital signatures 
    which are intended to signal that the signer is committing to the 
    content being signed. 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. 

    A transaction signed with a certificate that has this bit set may be 
    used to build a non-repudiation service which protects against the 
    signing entity falsely denying later on some action, excluding 
    certificate or CRL signing. 

    Note that it is not incorrect to refer to this keyUsage bit using the 
    identifier contentCommitment since it is how it has been renamed by 
    ISO and ITU in the ITU-T X.509 Corrigendum 3 (04/2004). Regardless of 
    the identifier used, the semantics of this bit is the same. 

Denis 

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com <http://www.atosorigin.com/>

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 7 Jun 2005 13:22:14 +0100

The only significant conclusion from widely deployed applications that I
know of is that it is common to require the presence of the DS bit when
adding integrity protection to a message, such as signing an e-mail.

This is currently supported by standards but would not be supported by
your proposal. That is why your proposal will not be acceptable in
practice.

I still think NR aware signing applications can make use of the DS/NR
bits in a local context as a means of selecting the appropriate
certificate when several signing certificates are available.

This is already done in e.g. use of national electronic ID concepts to
support web-service based tax declarations and other public services
where presence of the NR bit is used to select the CC signing cert
instead of the authentication cert (with DS bit set)among the set of
certificates issued by pre-approved CAs (complying to local bit setting
rules). These types of distinctions will not go away and can be locally
maintained despite lots of public confusion.

Maybe the problem is not as big as we tend to believe.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> On Behalf Of David P. Kemp
> Sent: den 3 juni 2005 21:49
> To: Stefan Santesson
> Cc: [email-masked]
> The argument is that that WAS the original definition, but it was so
> poorly worded
> that no developer could be confident of understanding it.  I'd be
> astonished if as
> many as one half of a percent of currently deployed applications don't
> look for
> bit B for data origin authentication.   When every application accepts
> bit A or
> bit B or both for data origin authentication, it's just as true to say
> that the
> proposal to use bit B is completely compatible with the deployed base
as
> to
> say that it's completely incompatible.
> 
> Even before the ABA got involved in X.509's usage of NR, the DoD
> certificate
> policy attempted to distance itself from content commitment by coining
the
> term "technical non-repudiation" to refer to the generation and
acceptance
> of persistent signatures - signatures for any purpose, including
integrity
> and data origin authentication, that did not involve a liveness test.
> And
> as Peter has noted, many developers share that interpretation but dare
not
> incorporate it into code lest they fail to accept any certificate that
> would
> be accepted by a competing application.
> 
> Five years from now, I'll challenge you to point out any application
> that treats a signed message "I promise to give Popeye $5 tomorrow
> for a hamburger today" with the NR/CC bit set any differently than
> with it not set.  The old NR bit is meaningless to current
applications,
> and with the new X.509 definition it will continue to be meaningless
> to future applications.  We have lost the opportunity to rescue that
> bit from its meaningless existence.
> 
> Dave
> 
> 
> Stefan Santesson wrote:
> 
> >David,
> >
> >This would have been more useful if it had been proposed as the
original
> >definition. Unfortunately it is completely incompatible with deployed
> >base of applications which look for bit A (DS) for data origin
> >authentication.
> >
> >
> >/Stefan
> >
> >
> >
> >
> >>On Behalf Of David P. Kemp
> >>Sent: den 27 maj 2005 20:37
> >>To: [email-masked]
> >>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).
> >>
> >>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
> >>
> >>
> >>
> >>Peter Gutmann wrote:
> >>
> >>
> >>
> >>>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.
key
> >>>Peter.