Re: 3280bis: key usage (13)

["David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>]

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