RE: 3280bis: key usage (13)

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

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
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of David P. Kemp
> Sent: den 3 juni 2005 21:49
> To: Stefan Santesson
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: 3280bis: key usage (13)
> 
> 
> 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
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: owner-ietf-pkix@xxxxxxxxxxxx
> >>
> >>
> >[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> >
> >
> >>On Behalf Of David P. Kemp
> >>Sent: den 27 maj 2005 20:37
> >>To: ietf-pkix@xxxxxxx
> >>Subject: Re: 3280bis: key usage (13)
> >>
> >>
> >>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 <stephen.farrell@xxxxxxxxx> 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.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>   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.
> >>>
> >>>Peter.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
> >
>