Francisco,
Go back to your visa card example, which you present as an attribute:
creditcard: VISA number 234756 8476 387465
subjectSignature: "C=ES; L=Barcelona; PA=xxxx; CN=Francisco Jordan",
sn: 34 -- or other
issuerSignature: "C=ES; O=VISA", xxx
This raises many questions, like:
1) Why do you want your visa card number stored in your organisational entry?
In fact, why do you want your visa card be readable at all? There is a solid
privacy issue there.
2) Why do you want your visa card number qualified by your "distinguished"
name? It seems that the only question from the "vendors" point of view is
to check that this is a valid credit card (verify the visa signature) and
that it was not stolen (check VISA's CRL). They have no business checking
the subject identity. In fact, if you look at real life credit cards,
you will find something like "Francisco Jordan", not the complete string.
3) By the way, how can you check the validity of the certificate? How does the
restaurant owner in Honk-kong know that "C=ES; O=VISA" is a valid member of
the VISA system? In the "certificate is a relation" model, you would have
something like:
Cert:
Subject DN: "CN=Francisco Jordan, Number=234756 8476 387465,
OU=Spanish Branch, O=VISA, C=XX" -- pick one country --
Issuer DN: "OU=Spanish Branch, O=VISA C=XX"
sn: 23456789
which can easily be checked applying the PEM rules as the Spanish Branch's
certificate will be signed by "O=VISA, C=XX", the certificate of which is
presumably present in the card checking device..
By the way, you can apply the same checks to:
Subject: Francisco Jordan
<234756-8476-387465(_at_)Spanish-Branch(_dot_)VISA(_dot_)COM>
Issuer: Banco VISA de Espana <Spanish-Branch.VISA.COM>
Using the X.500 syntax does not buy you anything there.
Christian Huitema