[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Identity certification
>Hi Bob.
>
> I'm glad we're discussing this topic once again, in a more calm
>form this time. [The last time was on pem-dev, several years ago, when I
>first found out I couldn't use PEM because it required a DN and I couldn't
>get anyone to define a DN.] The lack of calmness last time was almost
>certainly my fault, BTW. I was annoyed at that frustration. I apologize,
>a bit belatedly, to you and Steve Kent.
I think we were all a little bit naive back then, certainly with respect to the
legalisms involved in using a corporate name and the whole intellectual
property minefield. I've certainly learned a lot about those areas since that
time.
>
>With digital signatures, we have a much better link to the authorship of
>something than just word choice. As long as the same key is used for
>signing what we read, that key *is* the best identity of the author.
>It is globally unique and it is tied to the author more strongly than
>a fingerprint -- since it is tied to something he posesses [the private key]
>*and* something he knows [a PIN or passphrase].
>
>If you want to call that key [or its hash] a kind of distinguished name,
>feel free.
>
I remember your suggestion about using the key itself as a DN. Nothing wrong
with doing that, or even deleting the DN entirely, at least for some
applications. Not _all_ applications, however.
>Ah - but it's not everyone who cares.
>
>To care, you have to have extended me credit. That's a risk. If you
>extended credit via a bank or credit card issuer, then it is the bank or
>card issuer who needs to know who I am and where to find me. You, the
>person accepting my card, don't need to know. You just need to get *your*
>payment. I can imagine structures with physical accountability in which
>there is nowhere a central database linking keys to human bodies. Each bank
>could generate its own linkages.
Yes, exactly. I haven't had time to read the SET spec recently, but I worked on
the SEPP spec for MasterCard. In those certificates there is NO implication of
identity. Most of the decision making is based on the credit card number, which
is sent encrypted to the acquiring bank. The credit card number is then
validated by comparing what you sent to a salted hash version of the credit
card number that is contained in the certificate. The certificate's primary
purpose is to authenticate that salted hash version of the credit card, and it
also provides the public key necessary to validate your digital signature.
The signature is not used in the traditional sense of providing a legally
binding signature (although going that route is an option in the event of a
prosecution), but is primarily used to protect against the possibility that you
stole someone else's credit card number and matching certificate.
>
>More generally, if you're taking a risk, you need to decide what kind of
>binding you want between a key and prosecutability of some human body.
>
>>And if you want to extend some of these applications a little further to
>>include business letters, then identity (at least the kind of identity you
>>derive from your association with an organization) does matter. And if you
>>extend it further yet, to the point of acting as a purchasing agent or a
>>contracting officer, then your identity matters a lot more.
>
>If you sign a business letter or P.O. in such a way as to act for the
>corporation, you need your key signed by the corporation. That certificate
>should also express what kind of authority you have been granted: permission
>to spend up to $500 on your own signature, permission to issue press
>releases, permission to open negotiations for purchase of other companies,
>.... You can do that by role, by specific permission, or whatever, and all of
>those possibilities are available in the structure I propose.
Yes, I agree. And all of those possibilities are also possible within
off-the-shelf X.509 V3!
>
>>You could validly claim that it isn't the identity that is so important, but
>>rather the role you play. I wouldn't argue with you there, but conventionally
>>we sign such documents with our names, and if we have a formal title or role,
>>with that title or role.
>
>Yes -- I realize that we conventionally use our given names for these
functions
>but I believe that the X.509 effort is an inappropriate carry-over of that
>convention into a new age where it's no longer needed. In this new age,
>we have digital signatures and pseudonyms. That doesn't make us any less
>people or any less trustworthy. It just means that we don't rely on old
>methods.
But again, that has nothing to do with X.509 but only conventional business
practices. Likewise, whether you encode the corporate name and your role in the
DN or in the alternateName field is somewhat immaterial as well. You can do it
either way. Some people are going to prefer the familiarity of tried and true
forms of business discourse, including names and titles, but you are free to
decide that yourself.
>The way I usually describe the difference between identity certs and the ones
>I propose is as follows:
>
>1. An identity cert gives you a strong binding [via digital signature]
>between a key and a text string [= Distinguished Name]. There is some less
>strong binding between that text string and a human being. The CA policy
>tries to make that strong, but compared to cryptographic strength, it's not
>strong.
OK so far. The message digest binds the document to a hash, the digital
signature binds the hash to a public key, the certificate binds the public key
to a named entity, and the CA, thorugh a social process, asserts that the named
entity in fact exists,and has whatever other rights and privileges are
asserted in the certificate other than tthe name. Conventionally they assert
that the named entity is globally unambigous, but they have no way of proving
that assertion unless the "name" is qualified by a series of hierarchical
naming authorities, either explicit or implicit. If you want to know more
detail, go see the CA's policy.
>There is an even more nebulous binding between the human being and
>permission to act for the corporation, or whatever.
I think that you can rest assured that no independent CA is going to issue a
cert that identifies someone as being the agent of a corporation without having
exercised a considerable amount of due diligence to ensure that is in fact
true. Otherwise, the CA's liabilities could be huge.
And of course in most of those cases it will be the corporation itself that
will be acting as the CA, and if the corporation/CA issues a certificate that
falsely identifies someone as being an agent of the corporation, they have just
hung themselves with their own rope.
>
> The identity cert lets a human assert a permission you, the
>verifier, can't check but it lets you file a complaint if you've been
>misled and identify the human body who misled you, so that he might be
>punished.
That's certainly one way of doing it.
>
>2. A generalized cert gives you a strong binding between a permission and
>the key employed. [Imagine having security clearance operate as in (1)
above!]
>Once you have the permission certified, you don't need the path to the
>human body, in most cases. This one, direct link -- bound cryptographically
>-- is far stronger than the 2 or 3 hop chain of bindings in (1), in which
>only the first link is cryptographically strong.
I agree! BUT YOU DON'T NEED A NEW CERTIFICATE FORMAT TO DO THIS!!
X.509 ALREADY SUIPPORTS THIS CAPABILITY!!!
I don't want to accuse you or anyone else of not having done their homework,
but I get the very strong impression that some people haven't read X.509 V3 in
detail. (Since it hasn't been officially published in hard copy form yet,
that's not totally surprising, but I thought that most of the people on this
list would have had access to the V3 spec and the proposed Draft Amendment
which lays out additional extensions.)
The basic capability provided by X.509 V3 is the ability to ARBITRARILY add new
extensions to the basic certificate format. These extensions are in the form of
X.500 attributes and are identified with a unique attribute OID. ANY company or
organization that wants to can create a new attribute, defining it any way they
please (in ASN.1), and ascribe whatever semantics they would like to it. It
would be convenient if the organization registered its name with ANSI at the
national level and got an OID at the same time, but that isn't a requirement.
ANSI will issue an OID without a name. And if that is too much trouble, DEC
(and perhaps some others) have created an X.500 attribute under their own OID
which allows any one in the world to create a unique OID by incorporating their
globally unique world wide telephone number, including country code.
The default case is for all these extension attributes to be optional, so UAs
that are unaware of some particular attributre do not need to worry about them
-- they just skip over them, display them in hex, or whatever.
However, extension attributes can also be marked as CRITICAL, in which case, if
the UA is unaware of how to process the information it is required to reject
the certificate (or at least involve a human in the decision making process).
So you are perfectly free to proliferate private attributes to your hearts
content, so long as either (1) you are the CA, or (2) can persuade your CA to
include that attribute in your certificate. (GTE's CyberTrust system will
support a virtual CA, so that smaller organizations won't have to set up and
operate their own highly secure CA functionality -- something that most
organizations would not be likely to do very well. In that case, the CyberTrust
folks will maintain the private key for your virtual CA in tamperproof
containers, and will protect them in the same way that any other company which
has a fiduciary responsibility to its customers is obligated to do.)
So conceptually, at least, when you want to obtain a certificate you would go
(electronically or in person) to your friendly neighborhood CA store, and say,
"Please, mister, could I have a certificate? And by the way, I am proud to be a
card carrying member of the Lexington Minuteman Chowder and Marching Society,
and I would like my membership number included in the certificate."
"No sweat, says the man. You are the third person today that wanted that. I
already know the attribute format from your prototype certificate definition,
and now all I have to do is call up the Society and have them confirm that you
actually are a member, and I'll send your certificate back to you by e-mail.
That'll be $10.00 for the certificate, plus $1.00 for the amount of time I have
to spend on the phone. Sign here."
Of course if it is the L.M.C.M.S. that is issuing the certificate to its
members, the process is even easier. In that case they might well dispense with
any form of identity, and simply include the membership number by itself,
either as a unique DN where they were the naming authority (c=US, S=MA,
l=Lexington, o="Lexington Chowder and Marching Society", serialNumber=1234), or
in the alternateName extension (where they might also put your e-mail address,
nickname, the instrument you play, or whatever.
I hope this clarifies some of these issues.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Jueneman@gte.com
1-617/466-2820
"The opinions expressed are my own, and may not
reflect the official position of GTE, if any, on this subject."
Follow-Ups: