[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
General Requirements (was Re: encodings, character sets, general requirements)
>firstname.lastname@example.org (Tony Bartoletti) writes:
>>> > Other requirements:
>>> > - Trust model must be a web (people want to choose whom they trust).
>>> > People must be able to choose whom they trust or consider
>>> > reliable roots (maybe with varying reliabilities).
>>>The trust model should be a "constrained web", not the current PGP
>>> - Bill
>>Are we dictating a single trust model, or simply asserting that we must
>>support "web" and "contrained-web" models, among others? Certainly, the
>>effort to explore a simpler certificate should nevertheless aim for support
>>of varied trust models.
[ Helpful responses from Bill Sommerfeld, Perry Metzger, and others omitted
for brevity, thank you all]
>If the constrained web model has the capability of being able
>to express all other models then it seems like a good system to use...
You (and others kind enough to respond) are of course correct. Suitable
restrictions on a connected graph lead to all other forms. I suppose that
I was prompted by (1) how a "constained web" might be defined, (2) do we
really intend to preclude the PGP free-for-all by some form of certificate structure.
I have carefully followed all threads in both ietf-pkix and spki, and I
applaud the opportunity to gain a fresh-look at the fundamental issues.
My own needs are host-to-host authentication and data traffic protection,
and I produced "hand-rolled" DSS keys to do the trick. I would like to
move toward something less provincial. Unfortunately, I once attempted
to "get-my-arms-around" SSL/X.509 and dislocated both shoulders :-)
This thread needs to be reworked. I am not sure that Encodings and
Character Sets are related to General Requirements except distantly.
I would like to see a consolidation of the "more certificate usages"
into a taxonomy of sorts, as I feel that this should be the driving
force behind design (let the problems forge solutions, not vice-versa.)
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