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

Re: Certificate Variability

Carl Ellison wrote:
>At 22:12 3/13/96, Tony Bartoletti wrote:
>>In the spki discussion to date, at least two "straw-men" certificate
>>structures have been offered up to serve as anchors for discussion.
>>The first, I believe, was offered by Carl Ellison.  This "generalized"
>>certificate has the following minimal structure:
>>      Certifying-key:  <KEY_ID>
>>      Signed-key:      <KEY_ID>
>>      Validity:        <DATE_RANGE>
>>      Meaning:         <variable structure>
>>      (cert-key signature appended).
>>Another target was offered recently by Paul Leach:
>>      Cert-Name:       <DNS-name>
>>      Issuer-Name:     <DNS-name>
>>      Key:             <base64>
>>      Expires:         <RFC1123-date>
>>      Serial:          <RFC822-msgID>
>>      Sig:             <base64>
>        I like your analysis but don't believe that Paul and I are that far
>apart [as I indicated in my previous message to Paul].  In particular, if
>Paul were to relabel Cert-Name to Cert-Loc, then the label would be more
>true to the meaning of that field and would not suggest a kinship to
>X.509's use of DNs.  One *does* need to know where to find a given key.
>If Paul were only to add a Meaning field, so that this format doesn't
>suffer from the Vogon HQ problem, then I could see his proposal as a form
>of mine -- with no real conflict.

I was actually trying (albeit poorly) to highlight their similarities, and
I did not mean to focus primarily on the precise merits of either.  I was
hoping to draw out how the important twin goals of "wide generality" and "compact-simplicity", while not mutually exclusive, do present some degree
of challenge in addressing together.  My *central* question (appropriately
buried deep within the body of my posting:-) remains:

    When are two competing certificate models so different that they
    must belong in "different worlds", rather than be subsumed within
    a generic certificate handling framework?

In particular, is it possible (and desireable) to define a (very simple) uberstructure for certificate bodies, so that different cert-bodies could
be minimally handled (identified as to format-type and semantic ability, independent of content parsing) within a common operational framework.

By format-type, I mean structural specifics and encodings.  By semantic
abilities, I mean "Requires-CRL or not, Meaning-included or not, etc."

All SPKI-Compliant cert-handlers would be required to parse this minimal
shell, conveyed in a lowest-common-denominator form.

My thought is that cert-handlers could then have a front-end capable of
shuttling certificates about in an intelligent fashion, without having
to parse cert-contents in detail.  This division of labor also helps to
more cleanly divorce the structure & encoding issues from the semantic
model differences.


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