Re: [IETF-PKIX] OCSP and Cross-certification

[Mike Smith <mfsmith@xxxxxxxxxxxxx>]

Tim:

Well thought out reply to Mack.  I think the point you make about previously reported assumptions of "currency" is well made:  a responder may have "current" status on its own domain certificates in advance of the next CRL distribution cycle, but may have "latest" status based on published CRLs from its contracted CA domains.  In addition, some responders may only supply "latest" and no "current" status.

Michael

>>> Tim Moses <tim.moses@ENTRUST.COM> 12/12/97 07:07AM >>>
Mack - Thanks for your response.  I have a couple of comments that you
may enjoy considering.

I have some acquaintance with the use of OCSP in the NACHA demonstrator.
 However, it isn't clear to me whether this use is typical of those that
the author intends to address with his protocol.  I think, perhaps, that
(depending upon the usage pattern) it will be common for each OCSP
responder to serve a relatively small number (maybe in the low
thousands) of relying parties.  Each of these responders will (in turn)
obtain its revocation status information from the issuing CA, using CRLs
or cached OCSP responses.  A responder that directly serves the relying
party community may issue "live" responses, but the latency of
disemmination of revocation information will be dominated by the latency
of the mechanism by which the issuing CA serves the responders.   Used
in this way, OCSP does not offer better latency performance than CRLs.

You suggest that OCSP offers a better "cultural fit" to the banking
world than CRLs do.  Is this conclusion based upon the fact that in the
military world relying parties have an "employee" relationship with
their authority, whereas in the banking world relying parties have a
"customer" relationship with their authority?  As a result, relying
parties in the banking world will be less tolerant of a revocation
status service which is inappropriately packaged.  So, the service
should give a simple, unequivocal, YES/NO reponse to the query: "is this
certificate still valid?"

At first glance, there appears to be a lot of merit to this point of
view.  But, on closer examination, it seems to rest on a few
assumptions.  First of all, it assumes that the interface to the service
must be a wire protocol, when in fact, it is equally appropriate for the
service interface to be a client-side API.  In the latter case, the
information that flows in the wire protocol, to allow the API to make
its determination, is invisible to the service consumer, and therefore,
it does not have to be a simple boolean indication.

Secondly, the OCSP protocol does not give an unqualified YES/NO
response.  It "says" YES (or NO), but before you can trust this answer
you must use this key identifier to find a public key, check that it is
a key for the right algorithm, check that its usage is suitable for
verifying OCSP responses, check that it is valid, check that it has not
been revoked, check the signature on the response and check that the
timestamp on the response post-dates the time of the transaction.  How
can we determine that this degree of "qualification" is absolutely
acceptable, and a different degree of qualification is absolutely
unacceptable?  It seems arbitrary.  Or did I misunderstand your point.

Looking forward to your reaction. Best regards.  Tim.

>----------
>From:  Mack Hicks[SMTP:Mack.Hicks@BankAmerica.com]
>Sent:  Tuesday, December 09, 1997 12:58 PM
>To:    Tim Moses
>Cc:    ietf-pkix@lists.tandem.com
>Subject:       OCSP and Cross-certification
>
>
>Tim,
>
>From the last announcement by Entrust, IBM, and others, there is a
>perception that the cross-certification of CAs will handle the problem
>of trust generally.  This means that trees within each organization
>will trust trees within other organizations.
>
>Within the Banking industry, discussions uniformly have rejected this
>idea.  We have learned from long experience - with private networks,
>credit cards, funds transfer networks, and others - that the best
>way to manage the risk of a transaction, a connection, or a communication
>is to have on-line status checking.  This is also true with
>the checking of the status of digital certificates.
>
>The volume questions are interesting.  Bank of America processes about
>10% of the US paper checks every night -- over 22,000,000 pieces of paper
>at high water mark.  I think we can handle some multi-million certificate
>status requests.
>
>But we do not do things for free or manage risk of communication without
>authentication.  Therefore the on-line status check is for our customers.
>
>The NACHA Internet Council pilot of CA interoperability will demonstrate
>how Banks will trust each others certificates.
>
>We are using CRLs between banks--and I think CRLs have a place in high
>volume relationships between organizations. This risk of outdated CRLs
>can be managed by agreement and rules that NACHA would set.
>
>Tim wrote:
>
>>>1. Approximately how many OCSP responders are required to serve a
>>>community of one billion relying parties and subscribers?
>>>
>I expect that certificate holders would go to their agents.
>Therefore, the magnitude of OSCPs will be the magnitude of
>agents (essentially CAs or their repositories).
>
>>2. How do the relying parties come to trust the verification keys of the
>>>OCSP responders?
>>>
>By contracted relationship, since they are using the OCSP to THEIR
>agent - and the agent now deals with the trust to other repositories.
>Admittedly, this does make the same problem at the agent's level,
>but this is a less difficult problem since these agents are in this
>business.  They will have contracts and associations.
>
>>>3. How do the OCSP responders obtain revocation information from the
>>>single CA?
>>>
>Revocation information will be by OCSP at low volumes from agent to
>agent.  High volume agents will contract on risk distribution and
>may use CRL mechanisms.
>
>I do not know of a CA will offer its CRLs to all comers without
>authentication. (Talk about denial of service opportunities.)
>
>>>4. How current will the revocation information be when it is presented
>>>to the relying parties?
>>>
>If it is OCSP, it will be as current as represented by the agency.
>Between agencies, association rules and contracts will provide
>this assurance.
>
>
>For all the talk of CRLs, I would like to point out that CRLs
>make really good sense in a military application where the
>commanding officer (relying party) needs to make a decision
>based on available information (certificate, roots, last CRL).
>In a commercial context, we have left this model of behavior
>behind with the advent of telephony.
>
>
>
>Therefore, I state my earlier discussion:
>
>From PKIX 3, I expect that a PKIX compliant CA can
>
>a) Provide a place for CRL or OCSP
>b) Provide a reponse of
>   "I don't know you - go away"
>   for unauthenticated requests.
>c) The relying party should then not automatically trust
>   the certificate since there is no assurance that the
>   certificate is still valid.
>
>-   -    -    -    -    -    -    -    -    -    -    -    -
>Mack Hicks (415) 278-7230  -- Interactive Banking Division
>425 1st St m/s3671, SF CA 94105 <Mack.Hicks@BankAmerica.com>
>