Subject: Re: A Real Rationale for Dedicated Keys

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 21 Jul 2000 09:12:34 -0600

Hi, Aram,

Let me first observe that we seem to be greatly overloading a poor single NR bit.

Suggestions have been made that certain standards of key control must apply, that various time stamping and/or other certificate validation standards must apply, maybe some kind of biometrics must be used to protect against the possibility that they user accidentally or deliberately gave away his key or smart card, that somehow we have to have proof that what the user through he was signing was in fact what was signed, that the mechanism should somehow protect against multiple signature operations taking place during a single card insertion, and that somehow we should ensure that they user really intended to sign that particular transaction as his volitional act.  Whew!

But with respect to how the CA can or should know that the keys were properly generated, stored, and used, let me just say that I believe that is putting too much responsibility on the CA.

The contents of a certificate should be primarily viewed as a set of representations made by the subscriber to the CA, with the CA acting as a trusted witness.  If certificates are to be reasonably affordable, we cannot require that the CA employ a vast network of Pinkerton agents to go out and independently investigate the truth of every assertion made.  It should be sufficient that the CA verify the identity of the subscriber and the possession of the private key corresponding to the public key -- everything else should be viewed as a representation by the subscriber (not that the CA should turn a blind eye to an obvious error or falsehood.)

Particularly in the case of a digital signature certificate (less so in the case of encryption, but NR presumably doesn't apply there), if the subscriber claims a certain degree of key protection, and essentially says to the relying party, ":You can trust this transaction, because I have taken scrupulous care to ensure than no one can access my keys without my permission," then the subscriber would clearly have a very difficult time trying to repudiate the transaction based on a key compromise -- he would be hung with his own rope.

Bob

>>> Aram Perez <[email-masked]> 07/20/00 08:10PM >>>
Hi Tony B.,

> At 10:04 AM 7/21/00 +1000, Simon McMahon wrote:
>>> 
>>> Could you tell me what has NR (Non-Repudation) to do with CA control key
>>> generation.
>>> 
>> By "CA controlled key generation" I mean that the CA specifies minimum
>> standards and one option of the CA may be to do the key gen itself. The CA
>> should verify that the minimum standards are being followed if it specifies
>> any.
> 
> Agreed!
> 
>> Non-repudiation requires (at least) that the private key does not get
>> exposed or used by someone else without the owner knowing it. That means
>> that how the private key is used and how it is stored when not in use is
>> very relevant to NR. CAs can (and should) insist that key pairs are
>> generated and the private part is stored to some minimum standard before
>> they certify the public part.
> 
> Agreed!

Without the owner physically showing up, how can a CA know whether or not a
key pair was "generated and the private part is stored to some minimum
standard"?

Regards,
Aram Perez

[snip]

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 21 Jul 2000 11:30:43 -0700

At 09:22 AM 7/21/00 -0600, Bob Jueneman wrote:
>Tony,
>
>I agree that creating multiple certificates containing the same key is a 
>dumb idea, because it makes it very difficult to know which set of 
>assertions (contained in the certificate) were supposed to apply to a 
>given transaction.
>
>But since the individual CA cannot possible detect or prevent someone from 
>going to two different CAs with the same public key, and making two 
>different sets of assertions, complete with full-blown POP, the only 
>reasonable solution to to place the burden firmly on the subscriber/user.
>
>If he creates two certificates for the same key, one with NR and one 
>without (or any other assertion), then unless the certificate is bound to 
>the transaction by more than just the signature, the relying party should 
>be permitted to make his case using which ever certificate is most 
>favorable to his case.

I think I agree :)

For such a "burden" to be considered reasonable by the courts, there need be
some manner of evidence that this "should have been obvious" to the user.

There are ways to make this "reasonably obvious" to the user, but I don't
want "its there in black and white in chapter 6, paragraph 23 of our CP."

Nor do I want to force the user to "deduce" that the burden may fall upon
their shoulders, based only on the "common knowledge" that a signature may
be taken as having "NR-intent" when ANY extant certificate for that key
states NR=1.

(I once wrote, only half in jest, that archived with every NR-certificate
issued should be the voiceprint of the user, reciting the CP/CPS verbatim.)

Perhaps much of my fear come from ignorance of the actual implementations,
existing and proposed, by which such signatures would become affixed.

I recall learning, via conversations with Ed Gerck, that the strength
of DES (for one example) depends critically upon what the material
being encrypted.  A "random sentence" is not really random if it is
embedded in a (say) MS Word document, the entire body of which is
being encrypted, and for which the first block of "file" will be a
constant for practically all users.  This makes an entropy-based
attack to recover the key far easier to perform.

The point being, how will the user be assured that an operation is
covering precisely what is being presented?  Where such assurance is
lacking, reliance upon minimalist NR conditions become more dangerous.

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 21 Jul 2000 11:46:06 -0700

At 08:33 AM 7/21/00 -0700, Aram Perez wrote:
>Hi Simon M.,
> > The key generation device has its own private key and signs the cert 
> request
> > for the newly generated user key pair. The CA then knows that the key pair
> > originated in a device it (the CA) trusts and probably provides as part of
> > its service. The CA certifies the public key of the device so it can verify
> > the device's cert requests.
>
>I'll restate my question: If the CA does not physically see the device that
>generates the key pair, how can the CA know "that the key pair originated in
>a device it (the CA) trusts"? And if the CA provides the device "as part of
>its service", then I have to physically show up to get the device and
>participate in the key generation process.
>
> >
> > Such a device is obviously not cheap but without such a device the CA 
> cannot
> > control the quality of remotely generated keys or how the private key is
> > stored and protected from duplication (necessary for NR).
> >
> > Much more likely is that the owner *will* show up to the CA or one of its
> > RAs to get a NR certificate. Anything less will probably fail to meet the
> > legal requirements for NR and be worth no more than a NR=0 cert.
>
>While I mostly agree, what you are stating is impractical. Very few will use
>digital signatures that "meet the legal requirements for NR" if they have to
>physically show up to the CA.

Could not the CA (stocked with such devices) simply ship the device to the
purported subscriber?  If it is embedded with its own (CA established)
device-key, then the CA will be able to trust the device remotely.

As far as guaranteeing that the device landed in the hands of the right
person, this is harder.  Perhaps it will come with a biometric input that
captures the subscriber's "vitals" as part of the key-certificate request.

___tony___