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

[Russ Housley <housley@xxxxxxxxxx>]

Mike:

This is not necessarily so.  The use of extensions can limit the scope of
the "tree" that becomes valid as a result of cross-certification.  For
example, name constraints could result in a small subset of the
certificates issued by a CA being considered valid in the context path that
includes a cross certificate.

Russ


At 12:49 PM 12/9/97 -0700, Mike Smith wrote:
>Mack:
>
>You are probably aware of the following point, but thought I'd mention it
anyway;  Some cross-certification of CA schemes bring in not just the tree
of the CA cross-certified, but all of the Ca trees they have
cross-certififed and all of the CA's those have cross-certified, ... etc.
Could be one CA cross cert could bring in all CA trees.
>
>Scary from a Bank's point of view, eh?
>
>Michael
>
>>>> Mack Hicks <Mack.Hicks@BankAmerica.com> 12/09/97 10:58AM >>>
>
>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>
>












    !
>












    !
>












    !
>












>