At 1:38 AM +0100 8/14/07, Stephen Farrell wrote:
Stephen Kent wrote:
SPKI is not an IETF standard, and in earlier discussion on the list
I think we agreed to not include it.
Well, two things. I don't recall any explicit consensus to omit
spki, since we've not really got any concrete things on which we've
yet got a rough consensus (the draft charter handed to the IESG
I guess would be the first such).
I thought we had a message exchange on the topic and agreed that SPKI
was out of scope. My concern is that we keep talking as though the
syntax of a cert is at the heart of this problem, which I think is
just plain wrong. That's why a document like RFC 4398 is irrelevant.
Defining a format for storing any form of cert in the DNS is trivial,
because the DNS is not making use of the content to make decisions.
In contrast many of the proposed TAM use cases DO need to pay
attention to the contents of TAs (whether they be certs or not), in
order to support meaningful TA management.
Secondly, sure, spki isn't a standard, and isn't really in serious
use (afaik), but a putative WG could still agree to allocate a
tag. I think the chances of spki being seen as a serious distraction
to PKIX are pretty much zero these days, so that tag has no real
cost.
This is not a PKIX vs. SPKI issue. The IESG settled that a long time
ago when it killed the SPKI WG.
If all it takes is a tag, then the cost would be low for the authors,
but the cost could be quite high in other ways. For example, there
have been many papers that begin by saying that "... because X.509
requires a singly-rooted tree for a PKI ..." I spend way too much
time as a program committee member correcting that sort of error in
papers submitted to conferences. This type of misconception arises
repeatedly because other people don't take the time to strike such
nonsense, clueless authors read it, and then write bad papers.
Its potential benefit is really that it might raise some
technical issue that would otherwise have gone unnoticed, thus
improving TAM and PKIX and OpenPGP and all.
Your sentence above suggests that by considering SPKI we might
include additional functions that otherwise might not be present.
That seems to contradict the assertion that the cost would be
minimal, i.e., just a tag to identify the syntax.
If we do our job well, we'll generate requirements based on the
protocol contexts we specifically say we need to support.
Steve
