Re: Interpretation of KeyUsage?

[Lars Johansson <Lars.Johansson@xxxxxxxxxxxxxx>]

David P. Kemp wrote:
> 
> Amendment 1 to ISO 9594-8:1995(E) includes the following text under
> 12.2.2.3 Key Usage field:
> 
>  "Bits in the KeyUsage type are as follows:
> 
>    a) digitalSignature: for verifying digital signatures that have purposes
>       other than those identified in b), f), or g) below;
> 
>    b) nonRepudiation: for verifying digital signatures used in providing
>       a nonrepudiation service which protects against the signing entity
>       falsely denying some action (excluding certificate or CRL signing,
>       as in f) or g) below);
> 
>     ...
> 
>    f) keyCertSign: ...
>    g) cRLSign: ..."
> 
> My interpretation of this text is that a key which may be used only for
> authentication would have 'digitalSignature' set and 'nonRepudiation'
> not set (as everyone agrees, above).  But a key which is to be used
> only for signing contracts (and not for authentication) would have
> 'nonRepudiation' set and 'digitalSignature' *not* set.
> 
> A single key which may used for both purposes would, of course,
> have both bits set.  Lars' definition would disallow the issuance of
> a single key that could be used for both purposes, so I prefer the
> current DAM definition as it stands.

David,

"My definition" stemmed from the suggestion by Russ Housley. It wasn't 
my intention to propose a change to the X.509v3 DAM. However, just the
fact that we're having this discussion indicates that the text in the
DAM under subclause 12.2.2.3 might be too vague.

Your interpratation of KeyUsage is the same as what is today stated in
the SEIS certificate specification. I think that both yours and Russ'
interpretation are ok as long as we agree on one or the other. Not both
at the same time.

So, what I originally wanted was a key that may _only_ be used for non-
repudiation services and should by no means _never_ be used in
authentication 
protocols. If it would, then somebody may ask me to authenticate myself
by 
signing some random data that could be a hash of a text that give that
other
person permission to withdraw $1000 from my bank account. Since I would
only see the "random" hash value, I couldn't have any chance to check
what 
I was actually signing. That's why I wouldn't want to mix my
authentication
key with my key for non-repudiation. The question is how that should be
done according to the X.509v3 DAM.

Nevertheless, I understand the point you're making in your comment that
it should be _possible_ to indicate that a key may be used for both
authentication and non-repudiation. It could be useful for keys issued
under a less restrictive security policy, e.g. software keys for www-
browsers. So should we then stick to the original definition as you
propose?

Have we reached a common understanding of this issue?

Kind regards,
/Lars Johansson