RE: 3280bis: key usage (13)

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

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
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Stephen Farrell
> Sent: den 27 maj 2005 17:26
> To: Peter Gutmann
> Cc: Denis.Pinkas@xxxxxxxx; ietf-pkix@xxxxxxx
> Subject: Re: 3280bis: key usage (13)
> 
> 
> 
> 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:-(
> 
> >>    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,
> Stephen.
>