RE: Huge CRLs

SET makes very limited use of CRLs, because its design does not require much in the way if propogating revocation data, vs. local checking.

This was one of the design "flaws" found in the analysis of an early (private) draft

when the thinking on CRLs, revocation and compromise handling was being formed.

Processors and merchants are now a critical element in the propagation of A/CRLs to

the client to address root key and CA compromise/rollover, and

address processor compromise.

SET design requires merchants and clients to do CRL checking. Let us be quite

clear on this. And merchants are a critical point -

as the conduit for the transfer of infrastructure ARLs to the client. They

control whether clients receive notice of infrastructure or processor compromise.

SET has interesting msg relaying characteristics which affect security flowing

from certs. Clients prepare two items of confidential material. One is prepared

for the merchant, the other for the processor. Yet the client has only a direct transfer

channel to the merchant, who also controls the flow of ARL/CRL information

to the client, and thereby the security of the preparation of encrypted

material to the processor.

I almost feel there is design principle lurking here. Never allow one of a set

of recipients to control the flow of infrastructure revocation information to

the originator.

SET is noticeably different to https design as regards use of certs

and the security properties of apps which become dependent on PKI -

and particularly as revocation and revocation protocol issues affect

security of multiple sessions relating to a single transaction. https has

multiple (not merely 2) session support; encryption of a

single-transaction's elements can be conducted in parallel,

as with SET, but revocation information

can always be collected out of band from a source

that is controlled only by the originator, and there

can be are multiple independent connections to transfer

or gather session-encrypted information.