Bob,
The following comments are for friendly public, non-competitive, discussion. So
in response to your suggestion for evaluation:-
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.
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.
STT uses a variation of X.509 v1 certicates tuned for optimised encodings
and 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.
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.
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.
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.
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.
Peter.