Re: On-line revocation checking

["Housley, Russ" <housley@xxxxxxxxxx>]

Mack:

What protocols are being used for on-line validation?  And, does the private 
extension proposed in PKIX Part 1 provide all of the information necessary to 
perform on-line validation?

Russ

______________________________ Reply Separator _________________________________
Subject: On-line revocation checking
Author:  "G. Mack Hicks, VP Bank of America" <Mack.Hicks@bankamerica.com>
Date:    1/3/97 11:33 AM


For: IETF-PKI mail list
     CommerceNet PKI Mail list

Allow me to add to Francisco's question regarding on-line revocation.

There is a persistent belief that directories (repositories) will 
deliver to any user upon any request the CRL of designated CA's 
(designated by the CA as an 'official' repository) signed by the CA. The 
directory will also deliver all certificates for a particular 
Distinguished Name (DN) and there will be many for particular users like 
SSLv3 certs, S/MIME certs, signature certs, encryption certs, and so on.

I believe this flies in the face of the reality of on-line transaction 
cost structures and business models.

The CommerceNet PKI task force has several business models that are to 
be demonstrated. None of these provide for the model that is proposed by 
IETF. There is a "Relationship Validation Model" <URL: 
http://www.commerce.net/work/taskforces/pki/output.html#business> that 
provides for subscribers of a CA to request the repository for that CA 
for on-line certificate validation. It is the responsibility of the 
subscriber's repository to contact the repository of the subject 
certificate to validate the certificate. Repositories may exchange CRLs 
if the volume of traffic is sufficient.

To the point: It seems unreasonable to ask that a subscriber's 
repository provide unlimited service upon request from anyone with its 
remuneration provided by the subscriber. Rather, the subscriber should 
have contractual relationship with its CA and associated repository to 
provide certificate validation within the community of interest.

The futility of the current model (for free) allows for the following 
situation:

a) Subscriber sends a message to every member of the US
   congress (over 500 copies)
b) Each member of congress goes to the repository of the
   subscriber and asks for
   1) all certificates for the DN of the subscriber 
   2) latest CRL for the CA of the subscriber

The repository ends up with over messages for each single message of the 
subscriber. In addition, the receiver (who is the party that must rely 
on the message) has no contractual relationship with the CA of the 
subscriber and no contractual relationship with the repository.

Further, the receiver's system (browser, mailer, ...) must process -- 
Certificate list - finding the right one for this particular message. 
(Could be two - signature cert and encryption cert.) Then must grind 
through the CRL for to make sure the cert(s) are still good. This is 
quite a bit of work to do and proposes that all receiving software is 
able to determine the validation process for all certs within the 
community of interest.

Both IETF PKIX and NIST MISPC "allow" for on-line validation of 
certificates. <URL: http://csrc.nist.gov/pki/welcome.html#mispc> It is 
my impression of the business community that on-line validation is what 
is called for by business doing open commerce.

Finally, the work with NIST MISPC and IETF PKIX seems to be focused on 
the functions of the CA strictly. Therefore most of the heavy lifting 
(replys to messages, etc) is put to the repository and receiving 
software (emailer, browser, ...). To demonstrate interoperability and 
functionality, the easiest model is to have the repositories operate 
"for free" (i.e. without authentication). I agree, this facilitates 
testing; it does not enable electronic commerce.

For an implementation of a "relationship validation model" see the Zion 
Data Systems implementation for the repository for the state of Utah. (I 
have no URL reference, maybe someone can provide to the lists.)