[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Need for Start Date
At 10:26 PM 3/15/96 -0500, Carl Ellison wrote:
>At 18:02 3/14/96, Bill Frantz wrote:
>
>>It might be a good idea to add a Start-Date: to both these forms. This
>>date could mean either Issued-on: or Valid-from:. If this field is added,
>>it would allow automatic override of an old certificate by a newer one.
>>
>>SET uses a this protocol to revoke a Acquirer Payment Gateway certificate
>>when it has become compromised. They issue a new certificate and
>>physically replace the secret key and the certificate in the gateway. The
>>gateway sends the new certificate out whenever it is invoked to perform its
>>function. The more recent Issue-date on the new certificate insures that
>>it replaces the old certificate in merchant and cardholder caches.
>
>There's a problem with SET's use of a newer cert to implicitly invalidate
>an older one. That turns the new one into an implicit revocation
>certificate. That, in turn, requires some statement about the length of
>time you're allowed to trust the information you get when you check with
>the CA to find out if there's a CRL update, or a new revocation
>certificate. In none of your summary of SET did you mention such a time
>limit as a field in the certificate. Without that delta-time specified
>explicitly, you're forced to check with the CA, on-line, every time you are
>about to use a certificate.
Certificate data flow in SET works as follows: The merchant gets
certificates and CRLs from the Payment Gateway (PGWY). The cardholder gets
them from the merchant. As such, the PGWY is always in a position to
revoke its old certificate. (SET was designed to be usable thru email, as
well as online.) In any case, PGWYs will have short period certificates.
I think there is an implicit assumption that the network address of the
PGWY can not be spoofed, so if you address a message to it, that message
will go to the real PGWY. If merchant <-> PGWY communications go thru the
internet, this assumption is a weakness in the protocol.
Also, if a PGWY key is stolen, it could be used by a dishonest merchant
with the old PGWY certificate to steal credit card numbers until that
certificate expires. (Give the old certificate to the cardholder and the
decrypt the credit card number.) Compared with the current level of trust
of merchants with credit card numbers, this risk seems small.
CRLs are only required for the Certificate Authority above the
cardholder/merchant/PGWY leaf level. They contain two dates, called
thisUpdate and nextUpdate. These dates appear to determine the validity
period of the CRL. It is a matter of Acquirer policy whether CRLs are
issued for compromized PGWY and merchant keys. (N.B. CRLs are not needed
for merchant certificates because the merchant is not given sensitive
information (credit card numbers). The acquirer is the only entity who
cares about compromized merchant certificates, and it can handle the
problem with a database flag instead of a CRL.)
Regards - Bill
------------------------------------------------------------------------
Bill Frantz | The CDA means | Periwinkle -- Computer Consulting
(408)356-8506 | lost jobs and | 16345 Englewood Ave.
frantz@netcom.com | dead teenagers | Los Gatos, CA 95032, USA