Bob,
The following comments are for friendly public, non-competitive, discussion.
So in response to your suggestion for evaluation:-
Peter, I appreciate your thoughtful analysis, and will offer some comments
and/or explanation to clarify some of your points Since you posted this
response to pem-dev and it has relatively little to do with the PKI
infrastructure, I'm posting this reply to pem-dev and not the ietf-pkix list
(being mindful of Ali's concern about cross-posting). I am, however, going to
post these comments to the ietf-payments list, since all of those people are
not necessarily pem-dev subscribers.
I must stress that I am merely one of the team players, and by no means am I
speaking in any official capacity for MasterCard or any of the other
contributers to the SEPP spec -- including GTE.
I managed to partially implement the VISA/Microsoft STT spec
over the weekend. The design is clearly a component of a security system;
the specification conveys all that is necessary to implement the mechanics
of the payment protocol. Several other (unspecified) components are clearly
necessary to do anything really useful with the material.
I tried to do the same with the SEPP spec. The document tends
more to be of a system design, rather than a component spec, and seems rather
incomplete from the perspective of an implementor and an evaluator
of the trusted system. In particular, ASN.1 OIDs and some types are either
not defined or missing.
That is correct. We understand that there are some fill-in-the-blanks work that
still has to be done. And by opening up the dialog to include other members of
the community, there may be suggestions for other changes that will be adopted.
There is no question that the document will be revised, certainly before the
end of the year and perhaps earlier. If you can point out the missing types I
will make sure they are corrected. The same goes for some of the punctuation
and name capitalization -- our tech pubs people did a great job in turning out
the document very quickly, but they weren't necessarily ASN.1 experts!
The question of what OIDs to use for the private X.509 v3 extensions in the
SEPP spec is a difficult one to answer. If the ietf-payments WG can act quickly
enough, there is the possibility that the IETF could assign suitable OIDs for
these extensions. But in the meantime I have recommended that MasterCard file
for an OID and nationally-registered name with ANSI, so that they will have a
unique name and number under the Joint ISO-ITU name registration hierarchy. The
private attributes can then be registered under that number. Issuing the OID
can be done immediately after ANSI receives the official request, but as you
may know registering the name takes three months to allow for challenges.
(Banks and other financial institutions already have globally unique
identification numbers asigned to them and theoretically these could have been
as OIDs, but so far those naming hierarchies have not been brought under the
ISO-ITU standards for name registration. Likewise, although MasterCard would
certainly have preferred to register at an international level, and there is
consideration being given to allowing such registration under the ISO-ITU name
registration hierarchy under "country=ZZ," the procedures for that are not yet
in place.)
The major difference between the two specs, apart from trusted evaulation
properties, and implementability, relevant to the discussion oft seen
on pem-dev may be described as:-
SEPP uses an innovative X.509 v3-oriented CMS access protocol, with uniform
messaging security enveloping shared with the payment protocol's own messaging
transport.
One of the fundamental design goals of the IBM iKP spec that SEPP was based on
was to avoid the necessity of introducing cryptography anywhere it wasn't
absolutely required, so as to minimize the potential difficulties with various
country's export/import/usage restrictions. The payment protocol per se is
designed to be secure against fraud whether the basic transport layer is
secure or not.
Of course, in those countries where encryption is allowed, the use of a secure
channel provides additional protection against compromises of the user's
privacy when ordering Goods and Services and should be encouraged. But this
should work whether the transport mechanism is e-mail, e.g., MOSS; a secure
link to a web browser, or some other mechanism such as IP-SEC. (The browser
needs to have a authenticated certificate, but the customer doesn't necessarily
have to have one, since the customer's agent can randomly generate a key and
send it to the browser to be used to encrypt both directions. And yes, certain
basic precautions have to be taken during the generation of that key!)
STT uses a variation of X.509 v1 certicates tuned for optimised encodings
and real-world id structures for end-systems/terminals.
I'm not so sure of that. As I read their spec (and I don't find their Cambridge
notation to be nearly as easy to read as ASN.1), they include all of the
signatures of the Visa CA hierarchy in each "credential." That adds a
substantial amount of overhead that has to be transmitted with every
credential. The SEPP approach uses the more conventional technique of using
multiple certificates for the CA chain. And although at present the approach
requires the transmission of the complete chain of certificates from the
acquirer to the merchant once a day (to ensure that a current set is
available), plus the transmission of the complete chain to the cardholder at
the start of the transaction, the system is designed to support the eventual
incorporation of X.500 agents for certificate retrieval. With the intelligent
use of caching, I believe that the overall communications load can be reduced
to less than the STT spec.
It could be argued that their encodings are more tightly optimized than the
equivalent ASN.1, but I don't think the difference would be substantial. We
believe that the additional generality and standards-based approach is worth
whatever minor inefficiences might occur.
I don't understand your point about real-world id structures for
end-systems/terminals.
SEPP bases protection of the payment protocol on RSA/DES, versus STTs
more reasoned approach concerning RC4, international-DES/OAEP and RSA. The
difference seems to be one of SEPP goes lowest-comomon-denominator under
the international crypto-rules, whereas STT goes for maximal protection
allowed, in a keying-framework which can expand as NSA allows. Whereas
STT specifies the means of protecting the payment instructions with
DES, it also provides for the bulk encryption key exchange within the
STT spec, thereby linking payment security with messaging security. This
does not seem to be a feature of SEPP.
Don't think that we didn't discuss that particular issue at great length! The
SEPP protocol was carefully designed NOT to be dependent on RSA per se,
although that is currently the algorithm used for both signatures and key
exchange. Diffie-Helman could be used for key exchange, and Taher El Gamal at
Netscape would probably be delighted to see DSS or El Gamal used for
signatures.
There was (and is) a considerable sentiment for the use of "pure" RSA for the
encryption of the credit card number and other essential information sent to
the acquiring bank, but there was also an architectural concern expressed about
the limitations that might impose on the length of the information, and no one
wanted to do two RSA encryptions for this purpose. If we could be sure that we
could get export approval for a longer RSA key length, the use of a hybrid
system might have been avoidable. RSA plus single DES seemed like the most
reasonable compromise between the best possible security and exportability. We
believe that there was no chance at all that triple DES would be approved for
export, and we wanted to avoid proprietary algorithms that have not been
adequately evaluated for security. The fact that RC4 has been approved for
export is not necessarily its strongest selling point!
Although there is relatively little argument that single DES is approaching the
end of its useful life, the cryptanalytic threat has to be considered in the
context of a credit card transaction. We aren't moving billions or even
millions of dollars around with these keys. Each DES key is used only once, for
a single transaction whose average value is probably going to be around $100 or
less, and almost certainly less than $5000. By the time we get to the point
where a single DES key can be broken on demand for less than $5000 and thereby
effectively compromise individual cardholder's credit card numbers, we should
be able to transition to a system that does not rely on the secrecy of the
credit card number (maintained for compatibility with existing banking
systems), but instead will rely more completely on the digital signature being
validated at both the acquiring and issuing bank as part of the payment
authorization.
As I said earlier, the use of encryption to protect the messaging environment
is completely separate from the protection of the payment information. We do
use encryption from the cardholder to the Certificate Management System to
protect certain senstive data used to validate the cardholder during the
on-line certificate issuing process, but we recognize that there might be some
export problems in this area. If so, cardholders in those countries might have
to visit their issuing bank to apply for and be issued their certificates in
person.
Interestingly, both use ASN.1, or a minor variant, for notation and both use
BER, else a minor optimised variant, for encoding. Neither will require
ASN.1/CN application-oriented data-structure compilers for
quality-implementation.
SEPP uses ASN.1 with DER encoding throughout.
In summary its hard to evaulate the two documents, comparitively. The scope of
the two documents is different - one a component, the other a system.
Any errors and omissions are unintentional, but almost inevitable in the first
release of any document of this size and complexity. However, it is certainly
the intent to provide interoperable component-level specifications for all of
the necessary components, including the certificate generation process and the
Banknet interfaces. Comments pointing out such errors and omissions are
certainly welcome.
Thinking beyond their scope, one could characterise difference in terms of
speed of change of infrastructure. STT seems to go for gold; a "brand" new
system that will replace the old. SEPP seems to rather more evolve the older
banknet for the newer marketplace featuring gateways between worlds.
To my mind, the gateway approach is the only logical alternative. It is simply
out of the question to require virtually every bank in the world to suddenly
change to support a new standard or mode of operation. Changes to the global
banking infrastructure have to be made with a lot of caution and forethought,
regardless of how tantalizing the opportunities presented by electronic
commerce might be.
Overall, the STT material leaves me with the impression of being
far more carefully thought-out, from the security standpoint. SEPP seems
to be more politically and commercially astute.
I'm rather surprised by your first comment. Perhaps you mean that the STT spec
is more tightly integrated, including both message encryption and payment
security in one mechanism. The SEPP approach was designed to provide strong
security for the basic payment protocol, while supporting a variety of
different approaches and mechanisms for the messaging security, including no
message security at all if required in certain countries (e.g., France and
Russia). Carefully separating the two different functions was done very
deliberately, and took into account the essential business interests involved.
MasterCard is clearly in the business of providing a secure payment protocol.
MasterCard is clearly NOT in the business of dictating to merchants around the
world how they should implement privacy protection between themselves and their
customers. That can and should be a place where competition is allowed and
strongly supported. Bundling the two functions in one protocol will make
innovations in this area much more difficult, IMHO.
Bob
Robert R. Jueneman
GTE Laboratories
1-617-466-2820 Office
1-508-264-0485 Telecommuting