[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: On-line revocation checking
Anyone who wants a copy of the Zions Bank implementation document
referenced by Mack Hicks near the end of the posting below, can e-mail
their snail-mail address to mailto:pyeatrakas@wespay.org for a hard copy
(not available in electronic format).
G. Mack Hicks, VP Bank of America wrote:
>
> +----------------------------------------------------------------------+> This message was addressed to: pki@lists.commerce.net
> +----------------------------------------------------------------------+>
> --------------------------------- Francisco Wrote on 01/03/97
> From: (Francisco Fernandez Massaguer)
>
> In the Part I draft of PKIX (draft-ietf-pkix-ipki-part1-03.txt) document,
> (end of 3.3 section) it is considered the possibility of (future ?) on-line
> recovation checking approaches.
>
> I have reviewed:
>
> draft-ietf-pkix-ipki-part1-03.txt (Part I),
> draft-ietf-pkix-polfmwk-00.txt (Policy), and
> draft-ietf-pkix-ipki3cmd-02.txt (Part III)
>
> and apart from the mentioned 3.3 section in Part I and a little note in
> section 6.6.1 in the Policy document, I haven't found anything more about
> this theme.
>
> Is or will be this point considered in greater detail on some other of the
> various draft parts or versions of PKIX ?.
>
> Thanks.
> Francisco Fernandez.
> ------------------------------------------------------------------------> Francisco Fernandez Massaguer E-mail: ffernandez@ait.uvigo.es
> ETSI Telecomunicacion Vigo Tel: +34-86-812181
> Vigo, SPAIN Fax: +34-86-812116
> ------------------------------------------------------------------------> -- end of quote from Francisco ----------
>
> 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.)
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Anyone who wants a copy of the Zions Bank implementation document can
e-mail snail-mail address to mailto:pyeatrakas@wespay.org for a hard copy
(not available on the net).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++> --
Best Regards
Pete Yeatrakas WESPAY 1111 Bayhill Dr #150
San Bruno CA 94066-3035 http://www.wespay.com
PH: 1-415/871-8762 FAX 1-415/871-9326