[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: legal question about certs

There are several different basic issues that seem to be being addressed here:
1) What's a key?  What can you do with it?
2) What does certifying a key mean?  Does it ever make sense
	for a keyholder to _not_ want a certificate to exist?
3) Given 1 and 2, does it make sense for a certificate
	for a key to be signed with that key
	a) never, b) sometimes, or c) always?
4) Does the signature by the keyholder belong in the certificate's syntax,
	or is a separate signed message adequate?

The ABA Digital Signature Guidelines which Bob Jueneman references
have a very strong presumption that the purpose of a key is to 
identify that a specific named human being or business officer
has seen the material being signed, and perhaps agrees with it in some way,
and the certificate is to verify, to whatever degree of satisfaction
the users of the CA system are paying for, that the holder of the key
is really that specific being with that True Name, or that the being
with that True Name holds that key.  There are other views of what keys are,
and what keys are for, and what signatures mean, and some participants
in this list are quite vocal proponents of these views.  For instance,
Guideline (2) below might be replaced with "states some activity that the
key may be used for". (Most of us would agree with (1), (3), and (5),
and (4) is optional but often useful.)

If the purpose of a certificate is to certify that the keyholder
has the right or ability to do _X_, depending on function _X_,
it may be valuable to have the holder of the key sign the certificate,
either to provide non-repudiation, or to provide authentication.
Similar motives may apply for identity certificates.

For instance, a certificate saying that key RSA12345678 accepts email at
alice@kgbvax.ru may be less trustworthy than a certificate saying that
key RSA12345678 accepts email at alice@alice.com, co-signed by RSA12345678,
even though both were issued by Certs==This to a dark-haired woman with
a California Driver's License and an unexpired Soviet Union passport.
On the other hand, Certs==This could send email to that address,
encrypted with key 0x12345678, containing the certificate,
and if the recipient can't read it, they obviously don't hold the key.
Since this is the _Simple_ public key infrastructure group,
it's worth considering whether this co-signing needs to be
wedged into the signature mechanism, or should be a conventional
signed message with no particular syntax, or should use a separate
cert with the same syntax as the cert from Certs==This
(which may not fit in well with the hierarchical view of CAs.)

There are other times you'd like to refuse to acknowledge a cert; 
the canonical example being the cert from the KKK Real White Folks CA.
If the syntax requires that the keyholder sign a key for it to be valid,
then you don't have to worry about anyone accepting it, whereas if it's
not mandatory, then it can circulate out there and be used.
On the other hand, a cert from the Internet Credit Bureau rating you
as a Bad Credit Risk from June 97 to Dec. 97 may be something you'd like
to block (leaving your previous Good Credit Risk March97-Sept97 in place),
but it's probably not in the Public Interest to let you block it.

To me this implies that the right answer to "should certificates be
user-signed" is "sometimes", so it's probably a job for a separate cert,
or for a more general cert syntax which can certify statements like
"I agree with CreditBureau's Cert#987654".

>1.5  Certificate:  A message which at least
>(1) identifies the certification authority issuing it,
>(2) names or identifies its subscriber,
>(3) contains the subscriber's public key,
>(4) identifies its operational period, and
>(5) is digitally signed by the certification authority issuing it.

>4.1 Generating the key pair
>If the subscriber generates the key pair whose public key is to be listed in
>a certificate issued by a certification authority and accepted by the
>subscriber, the subscriber must generate that key pair using a trustworthy
>system.

Gakk!  The implied alternatives are subscriber generating keys with an
un-trustworthy system (not real bright), or having the keys generated
by the CA rather than the subscriber (which reduces to the previous case,
without the benefit of non-repudiation by the real subscriber.)


>Generally, that is the intent and practical effect of those statutes that
>have been passed to date. the intent is not to invalidate any existing
>practices, but to fairly narrowly define a new set of practices which would
>be given a somewhat more exalted status with respect to the burden of proof.

The clear intention of most of the US government's attempts at defining 
public key infrastructures has been to pre-empt alternative practices
and enforce a GAK model; some of the restrictions proposed in other
countries have been similar.  There have been some exceptions,
though most of them have been pushed in the "dual-use" direction.
 




#			Thanks;  Bill
# Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com
# You can get PGP outside the US at ftp.ox.ac.uk/pub/crypto/pgp
#   (If this is a mailing list or news, please Cc: me on replies.  Thanks.)
Follow-Ups: