Subject: A Real Rationale for Dedicated Keys

From: Tony Bartoletti <[email-masked]>
Date: Wed, 19 Jul 2000 17:02:40 -0700

The common rationale given for maintaining distinct keys
for distinct usages is to distinguish the "legal binding
signature" from "no intent but saw it" authentication or
message tamperproofing.  As I've argued in the "Signing
what you don't understand" thread, I see no way to prevent
the key-owner from having a key "multiply certified" as
a ploy to escape the "clutches" of NR in legal signature.
(Hence, legal or NR usage should invoke a more involved
protocol.)

My point being, the key-owner is the primary point of
control in enforcing a "one-key, one-cert" personal regime.

However, there is a strong rationale where the key-owner
is self-motivated in maintaining a strict separation of
keys and usages (even as it applies to the legal vs
authentication usage.) This is the Privacy Motivation.

If I "multiply-certify" a "legal signature" key (with its
implication of linkages to detailed personal identifying
information) as either a lightweight "someone@address"
key, or worse, as a blinded voting key, then I risk the
very real possibility that my certificates can become
aggregated according to the public key value, and used
to violate the anonymity expected of the latter uses.

___tony___

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

---

From: "Simon McMahon" <[email-masked]>
Date: Thu, 20 Jul 2000 19:05:01 +1000

> control in enforcing a "one-key, one-cert" personal regime.
The "key generator" is really the primary point of control and need not be
the same as the "key owner" (the one who makes signatures). Some CAs insist
on having some control over key origin, key generation, or at least the
equipment used to do it so that uncontrolled certifications and hackable
private keys can be avoided. I would expect that all commercial CAs that
generate certs intended for NR usage will have to control key generation.

Does it really matter how many certificates there are for a public key as
long as the one specifying NR relates to a private key that cannot be
duplicated ? I dont see how multiple certs for a key is a threat to
non-repudiation of signatures. Only private key exposure / duplication is.

Regards,

Simon McMahon.
ERACOM Pty. Ltd.

---

From: "Jean Abraham" <[email-masked]>
Date: Thu, 20 Jul 2000 12:40:42 +0300

Simon,

Could you tell me what has NR (Non-Repudation) to do with CA control key
generation.

Jean

-----Original Message-----
From: Simon McMahon [mailto:[email-masked]]
Sent: Thursday, July 20, 2000 12:05 PM
To: [email-masked]; Tony Bartoletti
Subject: Re: A Real Rationale for Dedicated Keys

Regards,

Simon McMahon.
ERACOM Pty. Ltd.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Jul 2000 17:48:17 -0400

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

---

From: "Simon McMahon" <[email-masked]>
Date: Fri, 21 Jul 2000 10:04:30 +1000

> Could you tell me what has NR (Non-Repudation) to do with CA control key
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.

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.

As a merchant I would be more inclined to trust NR signatures verified by
certs from a CA that operated this way than from a CA that only checked the
key owner's identity.

I know of one commercial CA that only certified public keys for key pairs
that it (the CA) generated. Their rationale was that they did not want the
risk of certifying a dodgy key pair because of the risk of bad publicity
undermining their reputation as a CA. The generated private key was
transfered securely to the client. They wanted to take the next step and
start storing the private key directly onto smart cards.

Regards,

Simon

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 20 Jul 2000 16:20:47 -0700

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___

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 20 Jul 2000 17:36:42 -0700

>should verify that the minimum standards are being followed if it specifies

Agreed!

>they certify the public part.

Agreed!

>certs from a CA that operated this way than from a CA that only checked the

Agreed!

>start storing the private key directly onto smart cards.

Some reservations here!  I would be wary of a process that actually
allows the "key-generating operator" to learn the value of the secret.

If there were ways to guarantee that the secret key were actually generated
"in the card", (and could not be extracted, of course) I would feel better
about such a process.

But, this does not address the issue of the dishonest user who would
have the corresponding public key "certified for authentication, NR=0",
use it for signing email receipts, and then try to repudiate a contract
by arguing they were fooled into signing it with their NR=0 usage.

I don't think "Just Say No" to key multi-certification will work.

What will?

___tony___

---

From: "Simon McMahon" <[email-masked]>
Date: Fri, 21 Jul 2000 11:41:31 +1000

> allows the "key-generating operator" to learn the value of the secret.
CA's have internal policies and procedures to prevent that and they have
good reason to follow them too since they are in the business of selling
trust.

> "in the card", (and could not be extracted, of course) I would feel better
Me too, but if the CA I have to use (and everybody else uses) does it their
way I have to accept it or not participate.

> I don't think "Just Say No" to key multi-certification will work.
As long as the dishonest user can be made accountable for their actions you
should have a workable solution. You can not prevent dishonesty, only raise
the cost for dishonest behaviour.

I am are not saying "no" to multi-certification. Just "no" to its use as a
repudiation defense. Appropriate CA policy can make it harder for the
dishonest user to make repudiation claims based on being "fooled". If the
user has declared that they will not multi-certify a NR=1 key down to NR=0,
then goes and does it anyway their repudiation claim is going to look pretty
weak.

Regards,

Simon McMahon
ERACOM Pty. Ltd.

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 20 Jul 2000 19:00:14 -0700

>then goes and does it anyway their repudiation claim is going to look pretty

OK, that is a good point.  Now, I set my mind to thinking of how
the (bad) user might argue that the policy was not conveyed to them,
and wonder how to "bind" the user's "expression of understanding"
into the certificate.

Granted, the user/subscriber is "duty-bound" to be aware of policy,
but in most instances (e.g., detailed credit card agreements) they
are not, and the laws are usually crafted to keep the foolish from
hurting themselves too badly.  The protocol for applying for and
receiving a (hypothetical) NR-certificate, especially through an
electronic transaction, will need to be both involved and rigorous,
in order to thwart a claim that "the policy wasn't obvious" or
"my screen displayed no policy".

___tony___

---

From: Aram Perez <[email-masked]>
Date: Thu, 20 Jul 2000 19:10:55 -0700

Hi Tony B.,

>> they certify the public part.

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: "Simon McMahon" <[email-masked]>
Date: Fri, 21 Jul 2000 14:00:49 +1000

> and wonder how to "bind" the user's "expression of understanding"
If the bad user gets away with it then the CA's policy or procedures failed.
Either the bad user or the CA is liable so someone will be held accountable
for it.

> hurting themselves too badly.

How can any party to an "agreement" not be duty-bound to be aware of policy
relating to the agreement ? But as you say laws will be crafted to minimise
losses where they aren't.

>  The protocol for applying for and

Thats for sure.
I personally doubt that legally enforcible NR-certificates will ever granted
fully on-line. You would need a legally enforcible on-line authentication of
the subject for a start. That sort of thing is usually done by an agent of
the CA sighting documents like passport, drivers license etc.

Simon.

---

From: "Simon McMahon" <[email-masked]>
Date: Fri, 21 Jul 2000 14:14:51 +1000

> key pair was "generated and the private part is stored to some minimum
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.

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.

Simon McMahon
ERACOM Pty. Ltd.

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 21 Jul 2000 11:20:48 +0200

> CAs will not certify without POP (certainly not NR without POP!).

This is just the contrary: A CA can issue a certificate without POP,
if the certificate contains the NR bit. Hence is the reason: That
certificate shall only be used in a trusted environment (e.g. *not*
a door lock) where, by some means, there is some assurance of *what*
is being signed; in particular, which document is being signed and
which format is being used for the signature. Since the certificate
shall only be used with a trusted sofwtare, it is possible to
mandate properties for that trusted software; in particular, that it
SHALL always include the identifier of the signer's certificate and
protect it under the digital signature.

As soon as the private key is *only* used with signature formats
that contain the identifier of the certificate protected under the
digital signature, this provides "real-time" POP. In other words,
only the entity owning the private key is able to include the right
certificate identifier. If a CA has issued a certificate without
POP, this does not matter anymore, since only the legitimate entity
able to use the private key will be able to sign under the
certificate that contains the matching public key. Security is a mix
of security mechanisms and security procedures. In this case, we
rely on "good cryptography" rather than security procedures (that
may be hard and long to verify "after the fact").

Denis

(further text deleted)

---

From: Aram Perez <[email-masked]>
Date: Fri, 21 Jul 2000 08:33:44 -0700

Hi Simon M.,

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

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

Just my opinion,
Aram Perez

---

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

>may be hard and long to verify "after the fact").

Denis,

What you write implies that NR-keys will not be employed by "ordinary
users" for undertaking mid-high level internet transactions.

Maybe that is a "good thing".

But while I support the real-time-POP, I question the guarantee that
the "right" person possess the key in the first place.

Are you suggesting that a CA might create a key-pair (via trusted
key-device) and then create/issue an NR-certificate under your
name, BEFORE (or EVER) ascertaining that the private key/device
is in your hands?

___tony___

---

From: "Jean Abraham" <[email-masked]>
Date: Sat, 22 Jul 2000 09:58:27 +0300

How could one sign or encrypt an email with a public key shouldnt a private
key be used.

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]]
Sent: Friday, July 21, 2000 3:37 AM
To: Simon McMahon; Jean Abraham; [email-masked]
Subject: Re: A Real Rationale for Dedicated Keys

Agreed!

Agreed!

Agreed!

What will?

___tony___

---

From: "Simon McMahon" <[email-masked]>
Date: Mon, 24 Jul 2000 14:38:04 +1000

Hi Aram,

> physically show up to the CA.
They just have to show up to an RA. You cant open a bank account without
showing up to a bank branch and authenticating yourself yourself. Bank staff
are required to sight authentication documentation usually including photo
ID such as a passport.

I suspect that any commercial CA will partner with some organisation that
has a branch network such as a Bank or Post Office to make showing up less
of a problem. Maybe even McDonalds will get into the RA business :-). Would
you like a certificate with that burger ?

You cant support trust to the level where NR is possible without
authenticating the subjects and making them accountable for what they
declare at registration time. E.g. that they understand their obligations
regarding their private key. This really has to happen OOB since most people
and organisations dont have an established authenticatable on-line presence.
Perhaps at some time people and organisations will have a sufficient level
of on-line identity so that they can be authenticated on line but they have
to start off-line somewhere.

I would suspect that NR=1 quality certificates will start with few big
businesses and filter down to small businesses that wish to participate,
then to individuals who may be used to NR=0 certificates.

Simon McMahon
ERACOM Pty. Ltd.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 24 Jul 2000 09:48:33 +0200

Tony,

See my response at the bottom.

> name, BEFORE (or EVER) ascertaining that the private key/device

No. It is not what I had in mind.

The scenario I am think of, does not imply that the CA creates the
key-pair. A user will ask the CA to have an identity associated with
a public key usable for NR purposes (i.e. with the NR bit set, DS
bit not set). The CA will of course keep track of the request (i.e.
will keep the registration information provides at that time). In
that case, after proper warning of the user, the CA does not need to
perform POP.

Denis

---

From: Aram Perez <[email-masked]>
Date: Mon, 24 Jul 2000 13:45:12 -0700

Hi Simon M.,

> are required to sight authentication documentation usually including photo

I haven't tried, but I believe that you can open up a bank account with one
of the "Internet Banks" without physically showing up.

> you like a certificate with that burger ?

The US Post Office has been trying to into the CA business for years without
success. And what is McDonalds going to prove? That you ordered a burger ;-)

> then to individuals who may be used to NR=0 certificates.

Again, I don't want to regurgitate last year's discussion on the validity of
the NR bit. I believe that you can have non-repudiation without NR=1, and
that I can repudiate, whether or not NR=1.

Regards,
Aram Perez

---

From: "Simon McMahon" <[email-masked]>
Date: Tue, 25 Jul 2000 16:56:08 +1000

Hi Aram,
> of the "Internet Banks" without physically showing up.
They must depend on some existing on-line identity that they can
authenticate you against or not care about your identity just the amount of
$$ you can deposit with them. How safe are your funds with these banks ? How
much credit do they give you ?
> that I can repudiate, whether or not NR=1.
Fair enough but this list has been discussing two uses of certificates, that
is NR-type signatures and authentication type ones (non-NR). Whether the
NR-bit is the mechanism to support that or not I dont know but it sounds
like something that should be decided soon to prevent implementations
diverging on this point and becoming less interoperable.

Regards,

Simon

---

From: Irene Gassko <[email-masked]>
Date: Tue, 25 Jul 2000 07:02:05 -0400

Hi folks,

>of the "Internet Banks" without physically showing up.
This this true. I  opened a bank account by mail just by filling out an
application they sent me and sending them a check. I believe that 
a money order would also be fine with them. 

Irene
----------------------------------------------------------------------------
-------------------------------------------------------
Irene Gassko			 Bell Laboratories		http://www.lucent.com
Lucent Technologies		Secure Technologies Dept.
1600 Osgood Street			 phone:	(978) 960-5767
Room 30-2-A31			 e-mail: 	[email-masked]
N. Andover, MA 01845		 fax: 	(978) 960-3240