Re: German Key Usage

["Simonetti David" <simonetti_david@xxxxxxx>]

Rather than looking at digitalSignature and nonRepudiation using their
normally-accepted definitions (as a mechanism and as a service,
respectively), instead look at them as both using the same digital
signature mechanism, but:  digitalSignature, for session-oriented
authentication which you would not normally repudiate (except perhaps by
recording the transactions); and nonRepudiation, for signing of objects
which may later be repudiated (without regard to how the private key is
managed).

Eugene C. (Gene) Williams wrote:
> 
> On the surface Paul's comments seem logical, however, I'm wondering why any
> process which authenticates privileges and access would not demand
> non-repudiation???  If a key, which has been copied for encryption key
> recovery purposes, is used for digital signatures associated with I&A as
> well as for encryption, it seems that we're back to the basic reason for not
> making copies of keys used for digital signatures.  Maybe I'm missing
> something...
> 
> v.r.
> 
> Gene
> 
> -----Original Message-----
>      All,
> 
>      I agree. What's wrong with one key/cert for
>      keyExchange/Encipherment *and* digitalSignature and a second for
>      nonRepudiation?
> 
>      Still two keys/certs: The first is used for privileges/access to
>      resources either encrypted or protected by some AC mechanism
>      requiring remote I&A. The second is used for consciously created
>      signatures that may have to stand up in court.
> 
>      This would appear to be the most fundamental distinction of
>      services from the user's or replying party's perspective.
> 
>      keyUsage is an assertion by the CA, so this split makes sense from
>      the PKI's perspective, as well: The primary functional difference
>      from the CA's point of view is the promise to support
>      non-repudiation by archiving certs/CRLs beyond all statutes of
>      limitations and that it has not archived a copy of the associated
>      private key.
> 
>      What I hope disappears is any possibility of interpreting
>      nonRepudiation "service" as applying to notaries and timestamps!
>      These are applications which require nonRepudiation keyUsage like
>      anybody else.
> 
>      Paul
> 
> ______________________________ Reply Separator
> _________________________________
> Subject: RE: German Key Usage
> Author:  lars.gu.johansson@posten.se [SMTP:lars.gu.johansson@posten.se]  at
> DISAHUB
> Date:    8/13/98 10:14 AM
> 
> Key users,
> 
> Seems to me that everyone agrees that it is essential
> to separate the two security services authentication and
> non-repudiation by using different keys. That's why I've
> previously supported the idea of never mix these key
> usages (DS and NR) in the same certificate.
> 
> However, if the intepretation of the bits, as some of you
> point out, should be that digitalSignature (DS) indicates a
> MECHANISM wheras nonRepudiation (NR) is a SERVICE,
> then indeed can there be a good reason for having both
> bits set.
> 
> In order to still achieve the separation of the authantication
> and non-repudiation service, I would propose the addition
> of yet another key usage bit, namely the authentication (A)
> SERVICE bit!
> 
> That could make sense: either the keyUsage field of the
> certificate has DS+A set, indicating an authentication
> service based on a digital signature mechanism. Or the
> certificate would have the keyUsage field set to DS+NR,
> indicating a non-repudiation service based on a digital
> signature mechanism.
> 
> (Thinking of it: Wouldn't it also be possible to implement an
> authentication service based on an data-encipherment
> mechanism? If so, then the keyUsage would be DE+A)
> 
> The drawback of this aproach is that it adds further complexity
> to an already quite complex concept. My only concern is that
> we can agree on ONE solution that everyone interpret the same
> way. Perhaps it's better to stick to the original idea of never
> combining the DS and NR bits? Opinions?
> 
> /Lars Johansson
> 
> +-------------------------------------------------------------+
> + For information about the cert-talk mailing list, including +
> + archives and how to subscribe and unsubscribe, visit:       +
> +          http://mail.structuredarts.com/cert-talk           +
> +-------------------------------------------------------------+

-- 
David Simonetti, Booz·Allen & Hamilton Inc.