[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RE: non-key-sharing
I hope that Peter will forgive my posting his private message to me to the
board, for he makes some points that are worth discussing, including the
nature of a Registration Authority vs. Certification Authority, and the
difference between "corporate" and "public" CAs.
Peter implies that the CA is more or less a lights-out, dumb software
function that merely does what it is told to do by the RA, which is doing
the real work, i.e., the due diligence investigation of the user's name
and/or other attributes. Why, then, does this function exist at all --
couldn't the RA do it equally well? If the issue is control over the
signing key, what difference does it make if what ever the RA signs/approves
is going to result in a certificate in any case?
I believe that there are the following distinct differences between an RA
and a CA, but I'm not sure that I have ever seen them spelled out:
1. The RA may be a local agent for a public utility form of CA, i.e., a CA
who is willing to issue certificates to all comers. In this case the RA is
delegated the due diligence function by the CA. Alternatively, the RA may be
the local corporate interface to an outsourced "virtual" CA which is issuing
certificates in the name of the corporation.
2.. Although it is the function of the RA to provide a local, face-to-face
interface to the subscriber, validate identification documents, etc., the CA
retains an important oversight and auditing function, which it ignores at
its peril, since it is the CA, not the RA, who is liable.
3. Another very important function which the CA must perform is the
centralized distribution and maintenance of certificates (via a directory or
whatever) as well a CRLs and/or other forms of certificate status checking.
4. Finally, the CA has the burden of assuring that the certificate was
indeed issued to and accepted by the identified subscriber. Although the RA
may hand over the certificate to the person who requested it, there is
always the possibility that false identification documents were presented.
So before the certificate is taken out of a pending state, the CA should
send out a formal notice to the identified subscriber, informing them that a
certificate has been issued, and what their obligations are to protect the
private key. In most cases, this should require a positive acknowledgment,
e.g., by using a secret PIN to confirm acceptance -- one that was sent out
Certified mail return receipt requested, address verification requested,
restricted delivery, or the international equivalent using Registered Mail.
Although these process may not be required for very low level certificates,
they are almost inescapable for higher-value certificates, and therefore
cost money, payable to either the CA or the RA. In most cases I would
expect this cost to be lumped into a single bill.
Finally, although the cost of issuing a certificate by an internal corporate
CA might very well be rather minimal, the cost of issuing a CA by a public
CA such as VeriSign, GTE, etc., has to factor in the cost of establishing
and continuing the business. Companies may decide their own pricing models
based on perceived value, and not necessarily on the cost of the raw
materials and labor. In particular, trust is rather intangible, and tends to
be worth what someone thinks it is worth. The cost of the server software
may have very little to do with the ultimate price.
Bob
>>> Peter Whittaker <pww@entrust.com> 11/11 11:09 AM >>>
Is it the certificate that is expensive, or the maintenance of the
binding? I know that may sound strange, but let me illustrate what I
mean....
The operations of the CA are "cheap": the CA issues a certificate that
binds an identity to a key, and possibly to some other interesting
properties, and may from time to time issue new certificates that bind
that identity - or an updated form of it, say, after a DN change - to
new keys or to new properties. The CA is just software, and so long as
it has not been told that the binding has been broken (revocation), it
may continue to do so. This allows for automated certificate/key
updates.
The expensive operation is the due diligence performed by the RA, and
the periodic maintenance of that due diligence. At the very least, the
RA must perform that due diligence prior to allowing the CA to issue
initial certificates, and it may, from time to time, have to remind its
community of the procedures for notification of compromise or what have
you that would break a binding.
This may seem a minor point, but I generally tell people that new
certificates are cheap, that is, issuing new certificates to an
end-entity can be done in an automated fashion for the purposes of DN
change, addition of new properties to a certificate, key update,
what-have-you.
So long as the due diligence performed by the RA remains valid, the
operations of the CA continue, and cheaply.
Thoughts,
pww
Peter Whittaker Entrust Key Validation Sequence: 7ORS-NGND-P6ZX
System Architect, SI mailto:pww@entrust.com Phone: +1 613 247 3485
Entrust Technologies http://www.entrust.com Fax: +1 613 247 3690
>----------
>From: Bob Jueneman[SMTP:BJUENEMAN@novell.com]
>Sent: Tuesday, November 11, 1997 12:42 PM
>To: Bob.Smart@cmis.CSIRO.AU; cme@cybercash.com; frantz@netcom.com
>Cc: spki@c2.net
>Subject: Re: non-key-sharing
>
>>
>>
>>I get the feeling that there is an underling assumption that key pairs are
>>a scarce resource. This is certainly not true in the SPKI case, although
>>it may be in the more general digital signature realm. In the banking
>>case, I specifically mentioned the assumption that the key pair used was
>>specific to the account.
>>
>>If key pairs are to be considered scarce, what technical and social steps
>>must we take to make them scarce? If they are not scarce, then people who
>>want to "informally delegate" them have no incentive not to share them. A
>>modest charge for a cert will only be a modest disincentive.
>>
>
>I don't think that the keys themsleves are scarce. Rather, it is that
>certificates are expensive, because of the administrative burden and
>liability implications of binding of the key to anything at all, whether an
>"identity" or a set of capabilities. (I'm using the term certificate in
the
>most generic sense, not tied to X.509 or any other format.)
>
>You can certainly make certificates inexpensive, but only by making them
>essentially worthless to the relying party.
>
>Bob
>
>Robert R. Jueneman
>Security Architect
>Novell, Inc.
>Network Services Division
>122 East 1700 South
>Provo, UT 84604
>801/861-7387
>bjueneman@novell.com
>
>"If you are tring to get to the moon, climbing a tree,
>although a step in the right direction, will not prove
>to be very helpful."
>
>"The most dangerous strategy is to cross the chasm in two leaps."
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Follow-Ups: