Some comments on two points raised in this discussion:
crocker(_at_)cybercash(_dot_)com Writes:
However, except for support of the original X.509 distinguished name and
certificate structure, none are very complicated or require much code
to support. Speaking for myself, I'd have no objection seeing some
simplification in this area.
From my point of view, the essential issue was to permit name forms
other than X.509 distinguished names, and most particularly to permit
the use of e-mail names. We might be able to reduce the number of
forms of identifiers, but if we retract back to the limitations of the
X.509 distinguished names, a major goal of the design will be lost.
I would have thought the addition of the RFC822Name extension field in the
X.509
v3 certificate format will solve most of the naming problems you encountered in
the past. I suggest we start factoring X.509 v3 into this discussion, with a
view to simplifying the naming options while retaining compatibility with both
an evolving RFC1422 infrastructure and with with the PGP-like approach.
Paul_Lambert-P15452(_at_)email(_dot_)mot(_dot_)com writes:
- Document a suggested trust model (maybe several if necessary).
I am not sure this is a good move. I see the whole field moving in a direction
in which user communities will have great flexibility in defining their own
trust models, and the standards and the products will provide them with the
tools needed to support such flexibility.
Warwick Ford