Subject: Re: A Real Rationale for Dedicated Keys

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

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.

Bob

>>> Tony Bartoletti <[email-masked]> 07/20/00 05:20PM >>>
At 05:48 PM 7/20/00 -0400, Stephen Kent wrote:
>Tony,
>
>You cited the ability of a user (or someone else) to bind a public key 
>into multiple certs, some with and some without the NR bit enabled as a 
>reason that the NR bit is not useful for the purpose I stated.  I think I 
>pointed out in my response to John Wary why this line of reasoning is not 
>necessarily true. It would be a mistake for a user to have the same public 
>key in multiple certs, and anyone other than the user should not be able 
>to effect POP and get a CA to issue a cert.  Yes, a user could act in this 
>inappropriate fashion, in some instances, but then too a user could 
>undermine most of the safeguards that we envision through negligent conduct.

Steve,

I agree with the main points, and I worked from the assumption that
CAs will not certify without POP (certainly not NR without POP!).

Thus, if a user (wisely, naively, or unscrupulously) has an NR-key
"differently certified", it is largely under the user's control,
since they are the only ones that can satisfy POP.

So, my tack becomes "How best to work from this assumption?"

Bad as such a practice may be, I asked myself how close one could come
to making such a situation "workable", and the answer (to me) was a
protocol that forces a conscious selection of certificate be bound
into the transaction.  (I suppose they will always have the "Ooops,
I thought I selected the NR=0 cert that time, honest mistake...) but
the signed content would at least implicate a usage (and for NR and
the RP, more importantly, the strength of a DN-Person binding that
is commensurate with such a usage.)

To a Relying Party, the value of the NR bit on ANY certificate for a
given key (even where the same key may have been lightly certified
elsewhere) is that someone (who but the CA?) has gone to greater
lengths to ensure the "reasonableness" of the DN as a reliable
indicator of an identifiable party.  (Of what value an NR-cert
binding a key to the DN-equivalent of "someone@mailbox"?)

To my understanding, a re-certification of such a "strong" key
does not in itself weaken the established DN-Entity binding.

(It DOES allow a "lightweight CA" to leverage the hard work
of the diligent NR-certifying CA ... Is that an issue?)

It (NR-bit) may also be a declaration from the CA that the key
was generated in a secure device.  But all of this lends a degree
of value to ANY use of the key, EXCEPT for a use requiring some
measure of anonymity.  Fortunately, the user is self-motivated
to employ a distinct key for such purposes.

As far as this being a reason that the "NR-bit is not useful"
for the purpose you stated, I am not quite sure.  From your
response to John Wray, I can only suppose that this use centers
on the reduction of "added mechanisms" to support Non-Repudiation.

But I feel that "additional mechanisms" are required for such
a weighty use as legally binding signatures.

I really want to avoid people buying into the semantic that
"Valid Signature" plus "I found a certificate that says NR"
somehow equates to "signature was made with NR intent."
(Even binding a selected NR-cert into the signature is
insufficient, but moves us a step closer.)

There are really two motivations I consider:

1.  What can be done to help prevent a "criminal" user from
     perpetrating a fraud.

2.  What can the legitimate user do to protect herself from
     misapplication by others.

If we agree that we cannot (easily) prevent a user from having
a key "multiply-certified", the goal must shift to how we might
best prevent the unscrupulous user from profiting by the practice.

My point about the privacy/anonymity issue is that the user has
legitimate control over this by applying different keys.

___tony___

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

---

From: Aram Perez <[email-masked]>
Date: Fri, 21 Jul 2000 09:54:39 -0700

Hi Bob J.,

> 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.

Whether it is dumb or not, I have personally heard a major financial
institution state that they plan to have at least 3 certificates for the
same key. The first is a self-signed certificate since they plan to run an
internal CA. The next is a certificate issued by the ABA, since they are a
member of ABA. And the third was a certificate issued by another major
organization (which I don't recall), again because they belong to that
organization.

And speaking of dumb, PKIX allows several dumb things to happen that are
perfectly legal according to the standards.

Regards,
Aram Perez

[snip]