Re: Issue with the requirements document: PKIX-centric terminology

[Russ Housley <housley@xxxxxxxxxxxx>]

I think that the protocol needs to be able to support X.509, OpenPGP, 
DNSSEC, and other protocol environments that make use of public keys 
for validating digital signatures.  That said, I strongly believe 
that the most urgent need is X.509, so that should be the 
priority.  From my reading of this mail list, no one is suggesting otherwise.

Jon Callas has described a situation where a trust anchor management 
protocol would be useful in Open PGP.  He is one of the experts in 
that protocol environment, so I do not need to build on his comments.

Steve Kent has reported that Mike St. Johns does not see a need for a 
trust anchor management protocol in the DNSSEC protocol 
environment.  I hope Mike is right, but I fear that he is not.  The 
politics are the impediment to deployment of the DNSSEC strict 
hierarchy.  As a result, alternatives to the strict hierarchy are 
emerging.  For example, the IESG just approved the publication of 
draft-weiler-dnssec-dlv as an Informational RFC.  There are may 
possible ways that this protocol could be used.  Personally, I hope 
the existence of an alternative will help sort out the politics 
around the strict hierarchy, but if that does not happen there may be 
a need for a trust anchor management protocol in the DNSSEC environment.

Stephen Farrell has stated that there is very low overhead in adding 
support for trust anchors beyond the X.509 environment.  He is 
certainly correct, at least from the syntax perspective.  CMS is 
primarily used with X.509 certificates, but it also supports other 
certificate formats.  At one point, Some folks in the Open PGP 
community were considering a document that would describe how to use 
PGP keys with CMS.  I do not know the status of that effort, but it 
has not yet reached IETF Last Call.  My point in raising this example 
is that the syntax is very straightforward, but there may be 
important things to say about the semantics in each protocol environment.

I think the best way forward it to design a protocol syntax that 
supports all of these protocol environments.  Flesh out the X.509 
environment semantics in the initial document, and then write other 
documents to address the semantics of the other protocol environments 
as the need (and interest) emerges.

Russ