[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>
>
>Tony,
>
>        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___

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