[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OCSP and Cross-certification
Mack, I tend to agree with you regarding the difficulty of implementing a
general, bidirectional, cross-certification model -- especially if there is
any implication of liability flow. Presumably that is why Verisign has not
yet bought into the IBM/Entrust model yet.
However, I would be interested in your comments regarding something I
recently posted on the SPKI list regarding unidirectional certification vis
a vis verifier-selected policy OID constraints, and in particular how you
would view this concept in a commercial environment.
I am increasingly inclined to view certification or cross-certification of
suordinate or peer CAs as soemthing similar to what Standard and Poors would
do for bonds, i.e., a rating service, not a liability-assuming guarantee.
If someone wants a guarantee, let them go buy an E&O insurance policy, or
vist their local cyber-notary.
I would therefore welcome technical contributions and/or your support for
the requirement for the necessary enhancements to OCSP to support a billing
mechanism for status checking, as well as errors and omissions insurance on
a per transaction basis.
Finally, the attached scenario for certificate validation, including policy
OIDs is the primary reason why I continue to believe that the parenthetical
remark in the second paragraph of 4.2.1.5 of part-1 is completely
unacceptable (it says, "applications withiout specific policy requirements
are not required to list acceptable policies, and may accept any valid
certificate regardless of policy erven if the extension is marked
critical.").
It occurs to me, however, that I may be incorrectly interpreting that
statement in the case where a Policy Constraint is applied. If the intent
of the spec (especially 4.2.1.12) is that a certificate which contains a
Policy Constraint attribute which is marked Critcal and contains a
requiresExplicitPolicy field essentially trumps the statement in 4.2.1.5,
then I am reasonably content. Although that isn't the way I read it, and I
would like to see the language clarified, if everyone else reads it the way
I believe was intended, then maybe I just need to get new glasses.
Bob
>
>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>
Date: Tue, 09 Dec 1997 10:04:36 -0700
From: Bob Jueneman <BJUENEMAN@novell.com>
To: cme@cybercash.com, egerck@laser.cps.softex.br
Cc: spki@c2.net
Subject: Closed loop paths of trust
Mime-Version: 1.0
Content-Type: text/plain
Content-Disposition: inline
> To me, there are not apples and speedboats. Rather, there is
authorization
>which is injected by the verifier into a so-called root key and passed
>from that root key through certificates, possibly constrained or
restricted,
>into the eventual request where it is delivered to the verifier as part of
a
>request for some kind of action. This model of trust computation fits all
>known certification examples. Even though it is foreign to X.509 thinking,
>in particular, it applies to X.509. The authorization in this example
flows
>in a loop (circuit) from verifier back to verifier. To use an electrical
>example, the verifier has both battery and ammeter.
>
> - Carl
At least with respect to X.509 v3 and the PKIX work, it is definitely not
foreign. There is a continuing and erroneous belief that X.509 is
inherently a top-down trust structure, but this is not the case.
Especially once smart cards with tamper-proof storage for root keys become
popular, I would expect that at least for large organizations the following
will occur:
1. The MIS or IT organization will issue smart cards containing one or more
public root keys created by the MIS/IT organization. The root keys will be
embedded in self-signed X.509 certificates containing the organization DN
(for convenience, primarily), together with validity periods, etc. These
certificate are not necessarily published anywhere, except in the smart
cards issued to employees, so as to minimize any potential liability that
might be caused by using that key to certify other keys.
2. The self-signed certificates will contain a PolicyConstraint OID
attribute, specifying what other CA's policies are to be considered
acceptable as far as official business is concerned.
3. The MIS/IT organization may choose to unilaterally cross-certify other
CAs that it trusts, and may in addition provide for policy OID mapping. For
example, for high value transactions, it might certify an internal CA used
to issue certificates to corporate officers. In addition, now that the State
of Utah has officially certified Digital Signature Trust Co as a licensed CA
under the Utah Digital Signature Act, they might certify certificates from
the State of Utah and from DSTC. Florida is about to adopt regulations
setting up a rather similar structure, and although it is unknown whether
either Utah or Florida will certify each other, the IT organization might
decide that Florida's certificates are good enough for their purposes, and
certify their public keys as well.
4. Eventually, Utah, Florida, and other states will get around to issuing
certificate to both public CAs like VeriSign, and to private corporations
who operate CAs for their own employees. These various CAs will not
necessarily meet the same strict standards for identification, technical
controls, liability, etc, nor should they. So the user's IT organization
(or the user himself) can create perhaps three categories of chains of
trust, called for example Classic, Gold, and Platinum, for various usages.
Using the policy mapping option, they can map to a hypothetical Utah Red,
White, and Blue series of certificates, to a Florida Pink, Aqua, and Stucco
series; and an Illinois Diamond, Ruby, and Pearl series. Eventually, those
licensed/accredited CAs may set up equivalent policy mapping controls to map
their series to say an IBM blue, bluer, and true blue series. (You can have
any color certificate you want from Ford, of course, as long as it is
black.)
5. Depending on the user's own trust requirements (suitably influenced or
constrained by corporate policy :-), individual applications, and even
different uses of an individual application (S/MIME, for example) may select
a particular color coded trust hierarchy, starting with the appropriate root
certificate and enforced by the policy OID constraints.
6. Once that initial selection is made, assuming that the user's software
correctly implements the certificate validation rules and that the various
intermediate CAs are legally or contractually constrained and audited
appropriately to ensure that the trust is really operable, the user/verifier
can select the appropriate trust environment for the intended use, and have
everything else happen automatically. In particular, and this is one of the
most important features, if the smart card is trusted and has the
intelligence to validate the certificate chain itself, a digital signature
can be validated without having to rely on untrusted software, OR ON LOCAL
DATABASES.
Since it is the user who chooses which root key to use for particular
applications (at least from the set that is provided to him by his IT
organization), the validation is neither top down, nor bottom up, but both,
in a loop, as Carl has discussed.
(Having said that, I am inclined to wonder whether, after all of this time
and discussion, the SPKI group has developed anything that is sufficiently
different from what the PKIX has developed to be worth the beans, or whether
this has merely been a rather arcane, theological exercise of no practical
benefit. Obviously Carl would disagree with that assessment, and I know him
well enough to know that he is quite sincere in his beliefs. But I would be
curious to know just who else among the vendor community is prepared to put
their money where their mouth is, and to commit to develop and support
actual products based on this specification?)
Bob
Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com
"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."
"The most dangerous strategy is to cross the chasm in two leaps."