[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: legal question about certs
I was going to try to disengage myself from this discussion, but Bill makes
some good points that I'd like to comment on.
>There are several different basic issues that seem to be being addressed
here:
>1) What's a key? What can you do with it?
There seem to be two different views, both of which can probably coexist,
and neither of which is necessarily superior to the other. One views the key
as being bound to and an extension (property of) the person named in the
certificate and can be used to authenticate that person's control over other
rights and privileges, some of which may be identified in or granted by that
certificate; the other views the fact that some person may know or control
the use of a key to be an interesting and sometimes inconvenient fact, but
attaches properties (in the computer science sense) to the key, rather than
to the person. The first view follows rather naturally from centuries of
jurisprudence, the second (arguably) flows from computer science principles,
where the fact that there is occasionally a human sitting behind a terminal
is not necessarily provable from within the computer system, and may not be
germane.
>2) What does certifying a key mean? Does it ever make sense
> for a keyholder to _not_ want a certificate to exist?
To the extent that the concept of a keyholder makes sense, in particular the
concept of a putative or alleged keyholder, rather than necessarily the
real, honest, exclusive keyholder, then yes. The fact that Billy Bobs CA
and Bait Shop creates a certificate which contains my name and some public
key may be a total fiction with respect to the assumption that I possess and
control that key. And if that key is used to sign a transaction for which
the person whose identity is bound to that key may be liable (me), then I
absolutely insist that all possible measures be taken to prevent such a
certificate from even being created, much less disseminated.
>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?
Seems to me that a certificate which is signed by the same key that is
contained within the certificate is a self-signed certificate. The structure
and other features of a certificate may be useful in administering the
validity period and other aspects of a self-signed certificate, but as far
as I can see, a self-signed certificate has no trust associated with it in
and of itself. Instead, the trust must come from some independent, out of
band association with a trusted principal. So the answer is "sometimes", but
very infrequently. At present I don't see that my answer would change,
whether I was speaking about a PKIX or an SPKI certificate.
4) Does the signature by the keyholder belong in the certificate's syntax,
> or is a separate signed message adequate?
To the (questionable) extent that a self-signed certificate makes sense, it
could be included in the certificate. that at least makes the circularity
of the argument painfully obvious. Putting it in a message which is
eventually validated by the certificate makes the trust relationship much
more obscure. Of course, if the message is signed by some other party and
no circularity exists, then that is the moral equivalent of an X.9
capabilities or attribute certificate, which may be tied to an identity
certificate. In all likelihood an X9 certificate would be easier to parse
than an e-mail message, but there I go talking about religion again.
>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.
I think that is a fair characterization. Note, however, that no particular
claims are made in the ABA Guidelines that this is the One True Path to
Enlightment.
>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.)
There is both a passage of time and technical maturity issue here. When the
ABA committee started its deliberations, PEM/X.509 v1 was basically the only
game in town, so alternate naming constructs hadn't even been invented yet (
at least in terms of the certificate structure. In addition, as I said
above, the certificate was viewed as being a representation of the person --
machines work for us, not the other way around.
As time has passed, however, the PKIX group has taken the position that an
X.500 style Distinguished Name is optional, as are all alternateSubjectName
extensions. so as a matter of fact you can have an use an X.509 certificate
that does not contain an traditional "identity" at all, but only optional
attributes or capabilities. This may cause some operational difficulties
with respect to browsing, searching, filing, and revoking such certificates,
but those problems can be circumvented one way or the other.
What might be more interesting would be to consider what legal standing, if
any, a certificate which did not contain any notion of identity might have.
I would tend to argue little or none, as I would also argue in the case of a
Kerberos ticket, except within the context o a particular
rights-granting/rights-consuming application with human users, i.e., a very
closed system.
>
>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.
It certainly isn't obvious to me that having the keyholder sign the
certificate aids in providing either non-repudiation or authentication. That
might be true, but you haven't made the case yet, or at least it hasn't
penetrated my sometimes thick skull. I believe this argument applies even
more strongly in the case of identity certificates, as I haven't thought as
much about the pure attribute certificates. But self-signed certificates
still seem to me to be an exercise in circular logic.
>
>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.
Doesn't follow, and doesn't prove anything. I often receive e-mail message
that I can't read, WHICH AREN'T EVEN ENCRYPTED. You are trying to prove a
negative. the implications you are trying to establish are even more
dangerous, and much more problematic, in the case of a digital signature
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.)
We should establish whether co-signing is anything more than an illusion,
first.
>
>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.
Nope. Still a circular argument. You are assuming that you have exclusive
possession of the private key, and someone learns about your real public key
and issues a certificate binding your name and/or affiliation to that key.
That's possible, and that's why the CA must demand that the subscriber prove
possession of the key before issuing the certificate, and its also true that
having the keyholder sign the certificate blocks that particular attack.
But the more likely case is that the CA merely invents a public/private key
pair that you don't know anything about, and ascribes that public key to
your identity while maintaining control of the private key. Now you are
screwed.
In one particular sense, that is one of the strongest reasons for viewing
certificates as purely an assertion about a key. Whoever/whatever has
possession of the key is thereby granted certain rights, regardless of their
identity.
Unfortunately, that view has relatively little utility outside of a pure
operating system context. Sooner or later, it comes down to binding that key
to some individual person or institution, and now the question of who
validly possesses that key DOES matter. In the old days, if a wheel fell
off a wagon and a man was crushed to death, the wheel would be punished by
being destroyed. by that reasoning, if a key misbehaves, i.e., is used in an
inappropriate way, it should be zeroized, assuming you can find it. But if a
person who possesses that key misbehaves, that person must be punished.
Since you can't send a key to jail, you have to send the person. so we have
to worry about the binding of the key to person, either at he beginning or
at the end.
In either case, ANY CA which makes an assertion about the binding of a key
to a some entity has to be viewed with some suspicion, as that CA could have
invented that key pair itself, without even the knowledge of the entity so
identified. A significant portion of the ABA Guidelines and such statutes as
the Utah Digital Signature Act are intended to address that possibility.
>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.
Note that it is YOU, not your key, that failed to pay your bills.
>
>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".
I suppose you could argue that solving half of the problem is better than
solving none of it. And I would concede that beneficial use of your key in
other contexts could be used to prove that you did in fact have possession
of that key, and therefore it was not a fictitious key minted by Billy Bob.
But this use of nontrustworthy CAs makes the job of nonrepudiation much more
difficult, and I am not convinced that the extra overhead in a certificate
is worth it. I'd rather just have the CA (or the CA's agent, the RA) simply
keep a wet-signed receipt that can be used to prove acceptance of the
certificate. Alternatively, some biometric technology could be applied, but
that involves a whole 'nother layer of complexity to get right.
>
>>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.)
Not real bright, but real, real common, unfortunately.
How many user key pairs do you know of that were generated on TCSEC-rated A1
systems using FIPS 140-1 rated level 4 cryptographic implementations? None,
you say? OK, how many key pairs do you know of that were at least generated
on a C2 rated system, using a FIPS 140-1 level 1 rated crypto? Again,
virtually none, you say?
I'm not much in favor of having keys generated by the CA, especially in the
light of the McCain/Kerrey S.909 bill, but the reality is that most CAs
could probably do a better job of key generation than most user software
running on Windows 95 -- witness the Netscape random number generator
problem. Of course, even the best keys can be subverted if they are
installed on a pond-scum platform running unaccredited software.
Novell's position on this issue is one in favor of Truth in Advertising --
certificates (and digital signatures) should contain a statement that
specifies what level of computer security rating the platform has, and what
cryptographic implementation rating, plus an assertion of what kind of
credential verification was performed. Before deciding whether or not to
accept a digital signature, a Greatest Lower Bound of these measures could
be calculated over the entire chain. and of course, in order to make sure
that these values are credible, there has to be some level of auditing and
contractual flow-down provisions in forced.
>
>
>>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.
>
McCain/Kerrey not withstanding, I don't think that is (yet) the case. I
haven't seen any particular or notable accomplishments in the CA area within
the federal government to date, or even any credible proposals, except for
those proposed for use by and within the government itself, and particularly
for DoD. That is not to say that some people may not have more ambitious
plans, but so far most of the action regarding legislative initiatives has
been at the state level, and only addresses digital signatures, not
encryption.
Bob
Follow-Ups: