[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
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: firstname.lastname@example.org phone: 510-422-3881 LLLLLLLL