[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: German Key Usage
I am troubled by the conflicted interpretations of NR/DS/Crypt usages.
First, I do understand the (at least) semantic distinction between
"DS in support of NR" and "DS in support of Authentication/Authorization."
The distinction can be seen most clearly by considering who has the most
to lose in an undiscovered key-compromise.
In the NR case, it is by far the key-owner who will suffer by the
inability to repudiate. In the "Authentication/Authorization" case,
it is the relying party (resource owner) who will suffer from the
diminished ability to control access to a resource.
But I am *most* bothered where I have seen it implied that key-escrow
need only be resisted in the NR-case.
It has become a habit, or "mantra" that the only justification for
key-escrow applies to data-encryption usage, and never to dig-sig.
I fear we will now be assaulted with "its ok to have DS-keys escrowed,
as long as the NR-bit is not set." This would be stepping on a very
slippery slope.
The DS/NR separation tends to weaken key-escrow's cage.
___tony___
At 01:50 PM 8/14/98 -0400, Simonetti David wrote:
>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.
>
>
Tony Bartoletti LL
SPI-NET GURU LL LL
Computer Security Technology Center LL LL LL
Lawrence Livermore National Lab LL LL LL
PO Box 808, L - 303 LL LL LLLLLLLL
Livermore, CA 94551-9900 LL LLLLLLLL
email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL