(c) The VISA/Microsoft concept of an STT credential, versus a certificate
(even though a credential is what we are all familar with technically as a
cert) is a very specific semantic shift designed for a closed-purpose,
payment-specific, key management framework in which the handling of liability
is quite different to the philosophy which you have espoused for open systems
for years, and seems (by your own words) to behind the Mastercard/GTE/... SEPP
work.
Several months ago, prior to becoming more seriously involved with MasterCard,
I learned that Microsoft and visa were conttemplating the use of a nonstandard
format. I had some correspondence with Warren Dent of Microsoft, where he tried
to explain what the difference was between their credential and any one else's
certificate (other than the proprietary format.)
At the heart of STT is the notion of authentication of cardholder
accounts and merchant accounts. STT is a secure payment system and is
designed specifically for payment purposes. As such it has no interest
in relating to personal "identity" of users. It is designed to provide
extremely high levels of "security". As such there is no need for
identity-type certification (X.509), but there is need for very large
key sizes for security protection. Also, because the credit card
associations have a world-wide purview it is important that the system
be appropriate for export. we have attained approval for use of our
large key sizes because we use affidavits that relate to payment
information only.
Both VISA and MasterCard have rejected the concept of using X.509
certificates for payment purposes and traded off identity for degree of
security. VISA in particular recognizes the liability factor for its
member banks, with whom we have also been working.
This seems to say that they confused the use of an X.509 certificate with the
notion of an identity-based "credential." I tried to clarify to him that X.509
is perfectly well suited to both pseudonymous and even anonymous users, as the
PEM Persona certificate demonstrates. I also tried to clarify the fact that the
use of a general purpose certificate format such as X.509 does not necessarily
mean that all sorts of export problems will ensue -- in particular that is why
we separated the signature certificates from the encryption certificates (just
as STT did). And I tried to tell him that if he was all that concerned about
export, he could use DSS for signatures and would probably get NSA's blessing
in a heartbeat. Unfortunately, he never responded.
Strangely, considering how they claim that they wanted to do something quite
different, the STT credential information borrowed a lot from the current X.509
concepts. There is a TV_CREDOWNER, which is a "subject name", there is a
TLV_ALTERNATE_NAME (which is undefined, but looks a lot like the subjectAltName
in X.509 v3), TLV_CREDROOTNAME, which denotes the trust tree in which this
credential is signed and which looks a lot like a certPolicySet in a
keyUsageRestrictions (although I'm not as clear about this concept as I would
like to be), and TV_CREDLEVEL, which appears to be the same as basicConstraints
(subjectType, pathLenConstraint, and subtreesConstraint) but less flexible.
Maybe I missed it, but I can't find a definition of the syntax of TV_CREDOWNER
other than Cstring. So I assume that it is just an undifferentiated string that
may contain the users name, address, etc., or who knows what. In any case, it
looks a lot like a Distinguished Name, except that it isn't guaranteed to be
distinguished, i.e., globally unique (that ought to make nonrepudiation more
interesting!), and it doesn't have typed subfields, which ought to make it lot
harder to parse. What price progress!
[At this point I had typed another 150 lines of brilliant anlysis comparing
credentials to certificates. But an errant keystroke mysteriously erased the
entire thing, and I doubt that I be that billiant twice in a row. Probably just
as well -- everyone's e-mail processor is probably getting tired of this by
now.]
Suffice it to say that the cardholder is issued an certificate that is
pseudonymous -- only the CMS knows the correlation between the certificate
number and the cardholder or the credit card number. The acquirer can validate
the credit card number against the certificate by virtue of the salted hash
trick, which I won't explain all over again.
All of the rest of the certificates, including all of STT's credentials really
are bona fide, identity-based certificates. In the case of SEPP, the acquirer's
identity is obfuscated by listing it in terms of the Bank Identification Number
rather than the name, because merchants consider which acquirer they use to
process their payments to be somewhat sensitive, but it wouldn't be
particularly difficult to find a list of BINs, I wouldn't think.
So Microsoft/Visa's claim that they don't use identity-based certificates seems
somewhat bogus, but since they haven't specified _what_ information is
contained in the TV_CREDOWNER it is difficult to say for certain.
I don't think that this is a substantial paradigm shift from the kind of open
systems I have alwasy espoused. Yes, the cardholder's certificate is not open,
although it could be -- cf. the subjectAltName. the point in that in credit
card processing, the merchant doesn't go after the cardholder who doesn't pay,
the issuing bank does. and the issuing bank charges a per transaction fee that
is proportional to the risk, so no one has an inordinate amount of liability.
But if the merchant doesn't ship the promised goods, the cardholder now has a
digitally signed receipt, and nonrepudiation cuts boths ways. So this truly is
an open system, for everyone except the cardholders.
And in my heart of hearts, I believe that if we can get to the point of having
legally-binding caveats and conditions included by reference in the certificate
itself, not by just an OID but a signed URL or DN that points to an online
policy document, both for the CA and the user, that the credit card companies
will be willing to undertake the slight additional risk of using those
certificates for more general purposes. Of else the cardholders will just have
to go somewhere else for their general-purpose, identity based signature
certificates, and probably their encryption certificates as well.
What doesn't make much sense to me is setting up the all of the certificate
infrastructure necessary to support STT, and then have to use some other
infrastructure to carry out the shopping portion, or other web-browser
functions.
Bob