[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Staged Certificate Validation


I should have made clear that the (hash of) was optional.  This was intended
to put structure to the forms submitted by Greg Rose.  I would like some
element of each tag field to indicate whether the field holds a hash or the
actual value.  To my understanding of Greg's model, an application might "explode" a certificate into its elements, (adding in other unsigned items
as well) and use the hash of each element as an index into cache or storage.  Wherever cert-space might be conserved by use of a hash, a CA could establish the practice of using such for certain fields.

It strikes me both as a lot of indirection (hassle) but also a bit elegant
in making an application's cache-look-up procedures almost trivial, and
makes it possible to create all sorts of (monster) associations by signing
bundles of hashes, to what ends I can barely imagine.  A simple example is
the "Purchase Order" from Greg's posting, where the tags on the left side
are understood to be hashes:
    PurchaseOrder23: "Agrees to pay for a pair of speakers"
    Statement10: "Not valid for more than $1000"
    Key123: hjfkedwui298342qyuibf...hjfsaew
  Then (PurchaseOrder23, Statement10, Cert7) signed by Key123 and
  accompanied by a copy of Cert7, represents a purchase order.

  Cert7 is in turn another signed bundle of hashes.  Makes my head hurt.

The real saving I propose is in having most all cert re-validation checks
conducted with the Outer-Cert only.

>>  (Cert-Info)
>>    Outer-Cert-ID/Serial
>>    (hash of) <CA_ID>
>>    (hash of) <CA_KEY> (or of CA-key-cert)
>>    (hash of) <CERT_LOC>
>>    (hash of) <CERT_VALIDITY>
>>  (Binding)
>>    (hash of) <(CA-Signature of) Referenced Certificate>
>>  [CA-Signature]
>But why have so many hashes?  The hashes will be larger than the base
>information.  Extra effort will be required to retrieve each of the missing
>pieces of information.  Am I misreading your notation?
>PS - to bad we don't have a standard design language :-)
>Paul Lambert                     Director of Security Products
>Oracle Corporation                       Phone: (415) 506-0370
>500 Oracle Parkway, Box 659410             Fax: (415) 413-2963
>Redwood Shores, CA  94065               palamber@us.oracle.com
>Date: 22 Mar 96 15:04:36
>From:"Tony Bartoletti" <owner-spki@c2.org>
>To: spki@c2.org
>Subject: Staged Certificate Validation
>The simplicity of the representation put forth by Greg Rose in the thread
>"make things as simple as possible" is compelling, both in the extensive
>use of hashes for elements, and for the freedom to create "certificate-
>like" things.  In particular, the idea of certifying the hash of another
>certificate suggested (to me) a way to provide (impose?) both a degree
>of structure, as well as a way to reduce bandwidth needs for much of the
>routine operations. (May even make up for the bandwidth I'm using here :-)
>This model might be called a "two-stage" certificate validation process.
>Two signed objects ("Outer" and "Inner" certificates) are retrieved when
>an "unknown" key is first presented.  I say two-stage because a validation
>request may result in only the receipt of the Outer-Cert, which is then
>used to request the Inner-Cert if this is a "first-time-seen" situation.
>The Inner-Cert is separately signed, and may come packaged with unsigned
>"addenda" such as the strings whose hashes appear in these certificates.
>This Inner-Cert can be passed about freely, with relying parties making
>requests for the Outer-Cert only, which "certifies" the Inner-Cert.
>The "Outer Cert" contains primarily the CA information, an arbitrary
>ID/Serial number, and the hash of the CA signature of an "Inner Cert".
>It also contains a "Cert Validity" date/interval that corresponds to
>the pkix "Expiry-Date" indicating how long the CA intends to be held
>responsible for its issuance, CRL-updates, etc.
>The "Inner Cert" is used to bind a signed key to a set of meanings.
>It contains no (necessary) reference to the CA, Cert-Location, etc.
>It *does* contain the matching ID/Serial number of the Outer-Cert,
>without which it is implicitly understood to be without force,
>regardless of the appended CA signature.
>It may also hold "Key Validity" date/interval(s) indicating when
>the Signed-Key is good for signing. (This is an extension presently
>being debated on the pkix list, and thank-you's to Bob Jueneman and
>Denis Pinkas for the "Private Key Validity Period" thread that helped
>to clarify the distinction for me.
>As a wrap-up, here is one depiction of the Inner and Outer Certificates:
>"Outer Cert" (Referencing Certificate)
>  (Cert-Info)
>    Outer-Cert-ID/Serial
>    (hash of) <CA_ID>
>    (hash of) <CA_KEY> (or of CA-key-cert)
>    (hash of) <CERT_LOC>
>    (hash of) <CERT_VALIDITY>
>  (Binding)
>    (hash of) <(CA-Signature of) Referenced Certificate>
>  [CA-Signature]
>"Inner Cert" (Referenced Certificate)
>  (Cert-Info)
>    (hash of) <Outer-Cert-ID/Serial>
>    (hash of) <KEY_VALIDITY>
>  (Binding)
>    (hash of) <SIGNED_KEY>
>    (hash of) <MEANING(S)>
>  [CA-Signature]
>In another form, the Inner-Cert could be a full pkix-style Identity cert,
>and the Outer-Cert could add additional priviledges detailed in the binding.
>In retrospect, that is closer to the form in the examples given by Greg.

Tony Bartoletti                                             LL
SPI Project Leader                                       LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: azb@llnl.gov   phone: 510-422-3881             LLLLLLLL