=>
=> Since the first time I thought about 'CertId' concept, I realized that
=> it had to contain information about certification hierarchy, so that
=> we can separate certification from naming hierarchy. I think that
=> X.500 DNs should be used for naming objects. The primary function of a
=> name (X.500 distinguished name or Internet domain name) is to
=> unambiguously and uniquely identify an object (person, machine,
=> application, etc.). It's my opinion that try to adapt names (mostly
=> DNs) because a certification need is not the way. For instance, there
=> exist situations where strict name subordination is natural, but
=> others do not, etc.
=>
I would like to challenge this assumption, and propose a different
paradigm,
i.e.
THERE IS NO SUCH THING AS A NAME
In fact, it is quite easy to prove this paradigm by a reduction ad
absurdio.
Given any set of symbols proposed as "your name", you can prove that it is
either ambiguous (there are probably many "Christian Huitema" in the
world),
or subject to change (huitema(_at_)sophia(_dot_)inria(_dot_)fr may be a
temporary mailbox)
or
only reflects one facet of your identity (<huitema, sophia, inria, fr>
versus
<Huitema, Antibes, France> versus <Huitema, IAB, Internet Society>).
Know, when you admit that, you may ask the next question. What is the
purpose
of certification? I pretend that the goal is *not* to assert your name,
but to
assert that the certified object possess some "attributes" that grant some
priviledge, or some function. When you are receiving mail, you want to be
sure
of the qualification of the mail sender. When you are sending mail, you
want
to be sure that you are accessing the correct destination. When you are
granting access to a document in a file server, you want to be sure that
the
person is a member of the correct group. Hence the second paradigm:
A CERTIFICATE IS A PROOF OF QUALIFICATION
Which mean indeed that one person should have many of them. Like one for
mailbox attachment, one for bank account, one for group X membership, etc.
Christian,
If you admit that names are ambiguous, then you are ambiguously qualifying
objects. So, from your words:
Given any set of symbols proposed as "qualification, function,
...etc.", you can prove that it is
either ambiguous (there are probably many person that will have an
account in the same
bank, there are millions people having a VISA or MASTERCARD, etc.).
Having the following two certificates:
Cert 1:
issuerDN: "C=ES; O=VISA"
subjectDN: "C=ES; O=VISA; CN=Francisco Jordan"
sn: 34
Cert 2:
issuerDN: "C=ES; O=VISA"
subjectDN: "C=ES; O=VISA; CN=Francisco Jordan"
sn: 48
How do you notice that Cert 1 was issued to a person named "Francisco
Jordan" in Barcelona and that Cert 2 was issued to a person named
"Francisco Jordan" in Sevilla?
By looking this Certs, and being formal, I can only deduce that "Francisco
Jordan" is an employee of VISA.
However, if the CA for VISA does the following:
Cert 1:
issuerDN: "C=ES; O=VISA"
subjectDN: "C=ES; L=Barcelona; PA=xxxx; CN=Francisco Jordan" or "C=ES;
O=UPC; CN=F.Jordan" (for a corporate card)
sn: 34
Cert 2:
issuerDN: "C=ES; O=VISA"
subjectDN: "C=ES; L=Sevilla; PA=yyyy; CN=Francisco Jordan" or "C=ES;
O=EXPO; CN=F.Jordan" (for a corporate card)
sn: 48
Now, You can at a glance assert that such a person must be a different
person.
From my point of view, the only thing that makes sense in a DN is that it
unambiguously and uniquely identifies an object. The only thing that makes
sense in a Certificate is that it corroborates the identity of an object.
Understanding by object a person, a machine, an application, etc.
I understand the fact that the same object be expressed as a residential or
organizational persons, but I can not conceive the fact that the same
object be expressed as a unlimited collection of names each one expressing
a particular function or privilege.
Definitively, you are talking about "attribute certificates" (ANSI X9) or
"authenticated attributes" (PKCS#7) in which an issuer binds certain
function or privilege to a particular certified object.
In this way, for the example above, I prefer the following:
Cert:
issuerDN: "C=ES; L=Barcelona" -- residential CA
subjectDN: "C=ES; L=Barcelona; PA=xxxx; CN=Francisco Jordan"
sn: 34
or Cert:
issuerDN: "C=ES; O=UPC" -- organizational CA
subjectDN: "C=ES; O=UPC; CN=F.Jordan"
sn: 46
in which an issuer binds a public key to a name, of course after
corraborating the name. And then:
Attribute:
emailaddress: jordan(_at_)upc(_dot_)es
subjectSignature: "C=ES; O=UPC; CN=F.Jordan", 46, xxx -- or
other uniqueId
issuerSignature: "C=ES; O=UPC" or "C=ES; O=UPC; CN=postmaster" or even
"C=ES; O=UPC; CN=F.Jordan", xxx
Attribute:
creditcard: VISA number 234756 8476 387465
subjectSignature: "C=ES; L=Barcelona; PA=xxxx; CN=Francisco Jordan",
34 -- or other
issuerSignature: "C=ES; O=VISA", xxx
Attribute:
access control list: unix-user-id, unix-group-id, .....
...etc
In this way, an issuer and a subject mutually bind a function or privilege
to a name. It is up to the signer of an attribute to make sure about the
subject's credentials (and vice versa), and it is up to a recipient trust
in this attribute (for instance, validating signatures with trusted keys).
Currently, there can exist a lot of subjects without certificate, then you
can use as subjectSignature a unique information that identifies the
subject (textual name plus passport number, drive license, etc.) signing
the attribute the issuer only. In this case, only the issuer will trust
such attribute. Note that the issuer can also unambiguously identify the
attribute.
I think that things currently (in the non-electronic world) work in this
way.
Francisco Jordan