[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is meaning important?
Ben Laurie writes:
>There has been a lot of discussion on this list about the "meaning" of
>certificates. It seems to me that this may be beyond the scope of the
>specification we are supposed to be working towards (namely, a means to
>interchange public keys simply and interoperably).
>Of course, there are certain aspects of the meaning which must be established,
>in particular the data telling us where and how supporting data for the
>certificate may be obtained (for example, the cerificate of the CA).
>Could we not make useful progress by ignoring the question of CRLs, trust
>models and so on, and concentrating on the interchange aspects of the system?
>I'm not saying that these issues do not need to be addressed, just that there
>are many uses for certificates, and many different models for verifying them,
>all of which could be built on a single interchange methodology (maybe).
I tend to agree. This serves to help make the "interchange" issues distinct
(to what degree this is possible) from the validation/trust-model issues, and makes some sense to me. This was the thrust of my posting on "Certificate Variability".
The objection some have to this focus is understandable, though, as it is
hard to see exactly what needs to be communicated first. More generally,
such a generic-do-anything form (carrier or super-structure) will not suffice
for much, if there is little agreed-upon substructure. Greg Rose's posting
"make things as simple as possible" could be seen as leading too far in this
direction. Sand is "atomic" and can be used to form too many things.
The fact is, there is a certain amount of info-bits that must be interchanged
as part of any certificate-validation-key-exchange scheme, and the variability that the many-schemes require can be either in the "certificates" or in the
"network" (applications). However, the certificate is our opportunity to
provide some structure to this variability (for good or ill). If the form
is too rigidly narrow, or so wildly flexible that its content is effectively
opaque to all except the narrow application that can grok the given form, we
have really done little for interoperability.
Still, I maintain that some part of the "certificate" could be dedicated more
directly to pure-interchange issues. At least conceptually, such a division
provides "lines-in-the-sand" across which one can argue that a given piece of information does or does not belong.
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: email@example.com phone: 510-422-3881 LLLLLLLL