Peter, I sometimes wonder whether we are reading the same documents, for I
certainly can't agree with some of your conclusions.
The Visa people explained the semantic shift from a more straight-forward
business perpective: we don't want non-repudiation. We do want other
payment-oriented protection services though, which entail that the "credential
might serve as proxy for our current plastic cards, and the long-established
attached legal semantics."
Maybe that's what they said, or thought that's what they got. But in fact their
system is very similar to MasterCard's, except for the fact that none of the
semantics are specified in the STT spec.
Therefore, said Mr Visa, Mr Gates, design us a system of messaging, payment
and>key distribution which does this. (This is what I'm reading between the
lines.)
This analysis, one might say, cuts to the heart of it. Its not confusing to
me;>"the key distribution infrastructure shall NOT, UNDER ANY CIRCUMSTANCES,
provide for >a repudiable 'digital signature'" said, in paraphrase, a VISA
economist to>Verisign at >a recent briefing. (And these are the guys who
perform the risk arbitrage)
As Valdis says, I have trouble parsing that sentence. Presumably you meant to
say "provide for a _non_-repudiable digital signature."
I don't know the source of your quote about plastic proxies, and I wasn't at
the briefing, so I don't know what was said or what was intended. But I can
read their spec -- at least the English part -- and I see VERY little
difference in the degree of nonrepudiation provided between the two systems.
Examining the STT spec, you can clearly see the following points, which are set
off in boxes to make sure that they are not missed:
2.2 (page 5) "Payment information integrity is ensured by the use of digital
signatures." [That's fine, but if that is all they needed, a hash within the
encrypted message would have been sufficient. They didn't need to use a digital
signature. RRJ]
2.3 (page 5) "Cardholder account authrntication is ensured by the use of
digital signatures and cardholder credentials." [Although SEPP makes use of a
more secure hash function, virtually identical mechanisms are used for this
purpose. -- RRJ]
In fact, these business requirements were written jointly by Visa and
MasterCard earlier in the process. Compare the STT statements against SEPP Part
1, page 4, para 3.1, 3.2, and 3.3, which say essentially the same thing and
even use the same wording in parts.
Also see STT page 12, para 4.2.5, where it discusses credentials. Whereas the
SEPP spec specifically addresses the issue of cardholder privacy, STT says "For
example, a Credeential Authority could supply credentials that offer a high
assurance of personal identity, which may be required for conducting business
transactions; this Credential Authority creates a message containing Alice's
name and her public key. This message, known as a credential [and known to the
rest of the world as a certificate -- RRJ], is digitally signed by the
Credential Authority. It contains owner identification information, as well as
copies of both the owner's public keys ("key exchange" and "signature"). to get
the most benefit, the public key of the Credential Authority should be known to
as many peopole as possible. Thus, by trusting a single key, an entire
hierarchy can be established in which we can have a high degree of trust."
STT page 15, para 4.3.5, further discusses the Hierarchy of Trust, and states
that the validity of the credential is assured by following the trust tree to a
known trusted party (either the Issuer or the Association on behalf of the
Issuer).
As I said, the STT spec provides almost nothing in the form of semantic
content, and this is true in para 5.1.2 as well, where the possibility is
mentioned that a company which issues proprietary card could perform all three
steps (registration requests, approval, and issuance of credentials), or a
financial instution could receive and approve the requrest and forward them to
the Association for issuance, or the requrests could be received by an
independent Registration Authority that forwards the requests to the financial
institution for processing and the bankcard association issues the credentials.
Since they haven't defined the contents of the subject name or alternate name
in the certificate, it is impossible to determine what level of identification
is intended to be provided. In general, they seem to be leaving this open to
the credential issuing authority.
Likewise, since they don't state whether or not the CA saves any of the
information that was used to authorize the creation of the certificate and the
correlation with the credit card number, it is impossible to say whether they
would be prepared to support nonrepudiation or not.
But:
1. If the credential contains the cardholder's "real" name, then
nonrepudiation is provided to exactly the same extent is in PEM and other
similar systems. (SEPP could also do this, as in the case of the merchant's and
financial institution's certificates)
2. If the cardholder's real name is replaced with a serial number known to the
credential issuing institution, then nonrepudiation can be accomplished with
the intervention of the CA, whether voluntarily or by subpoena. (As is the case
with SEPP).
3. If the subject name and alternate names are left blank, then nonrepudiation
would not be provided except by tying the Payment Instruction to the account
number, which is validated by the issuing institution. (Which SEPP could also
do if the banks or issuing institutions chose to.)
The STT spec, page 63, para 6.6 contains the statement "An STT credential
represents a binding between a banking account number, such as a cardholder
bank card number or a merchant BIN number, and an RSA key-exchange key or RSA
signature key. There is an analogy to certificates in other public key systems.
However, credentials are specialized to STT, they do not affirm general
identity, and must not be mistaken for certificates."
The validaty of that statement cannot be confirmed by the STT spec, which does
not define the semantics of the TV-CREDOWNER or TLV_ALTERNATE_NAME, nor the
processes in use at the "credential" authority. but there is certainly nothing
in the credential/certificate that would prohibit PRECISELY the same
nonrepudiation capability as that provided by SEPP
SEPP says: digital signatures are a mechanism with which to provide for
non-repudiation security services required by modern trade. STT seems to
say; RSADecrypt() is merely a way of releasing payment instructions
having undertaken assured key distribution for the confidentiality channel.
No. Both systems have effectively IDENTICAL capabilities in this regard, except
that STT uses a nonstandard certificate format and has not defined the semantic
content of the credential. Whether the nonstandard format was an attempt to
avoid any possible liability for the CA for unauthorized actions by the
cardholder, or whether it wasmerely an attempt to establish a Microsoft
hegemony through the use of a proprietary system, or both, is not clear.
How does this relate to PEM and MOSS design upon which we are here to comment?
MOSS reacted to 1422 by making 1422 an option which does something with all
that non-repudiation stuff.
It preserved it, but allowed users to avoid using it if they chose to.
I think STT says, the security objectives of
1421/1422, are not wanted in a payment system, period.
I have to disagree strongly. The system for validating credentials, from the
cardholder to the Payment System, all requires the same hierarchical system of
trust that PEM effectively uses.
I believe now that >SEPP says something more like PEM, with a mandatory MC
versus MIT>CA hierarchy,
Yes, there is an MC hierarchy, just like there is a Visa hierarchy.
and designs for a world of non-repudiation with a massive
great MISSI-style CMS to match.
No, non-repudiation is not really the issue. I am left breathless by your
"massive great MISSI-style CMS to match" hyperbole, but I have to point out
that if the system is successful, we have to be expecting on the order of a
million merchants and maybe 50 to 100 million users within ten years (depending
on your estimates for web usage and electronic commerce growth). That scale
will of course dwarf MISSI, whether implemented by Visa, MasterCard, GTE,
Verisign, USPS, or someone else.
The ONLY difference I can see between the two systems is that Visa made no
attempt to (document their approach to) provide globally unambiguous names for
cardholders, merchants, financial institutions, etc., whereas MasterCard
spelled out their approach to providing unambigous names while protecting the
cardholder's privacy.
And oh yes, Visa/Microsoft doesn't appear to provide any mechanism for
credential revocation in the event of a key compromise, a merchant going out of
business or being dropped by the payment association. Once a certificate is
issued, it is apparently valid until it expires. That ought to inspire
confidence!
Its a fascinating, though esoteric, difference.
The difference seems to be that Visa took the business requirements that had
been jointly developed with MasterCard and gave them to Microsoft, who took the
data definitions of a prototype system they were developing, merged the two,
and called it a specification.
But I do refine a previous conclusion. It seems that STT does in
fact plan for a gateway world; at the the plastic/credential interface.
Subtle, but rather neat. Im beginning to like it, now I understand it.
Try to understand this. The two systems are VERY equivalent, with a gateway
(Payment System) provided between the Internet world and the Banknet world
which remains unchanged. Except possibly for minor differences in the way
transactions are handled by MasterCard and Visa between the acquiring banks and
the issuing banks (almost all of whom interface with both payment
associations), there is virtually NO major differences in the way that the
actual authorization process is carried out. Visa/Microsoft just didn't write
it down, and they used a nonstandard format to make sure that it would be more
difficult for other players to catch up.
(Of course, it might be interesting to ask who is going to own the Payment
System, and how many will there be? Is Microsoft going to become an Acquirer,
and run all of these trasnactions through a common system which they control,
aided and abetted by their Microsoft network and Windows 95 strategy? See, I
can be as paranoid as the next guy!)
Bob
Robert R. Jueneman
GTE Laboratories
1-617-466-2820 Office
1-508-264-0485 Telecommuting