Re: Nits in current drafts

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

Ben Harris <bjh21%bjh21.me.uk@localhost> writes:

>I still think a better approach at this stage would be to simply remove all
>mention of OpenPGP keys and leave their handling to be defined properly in a
>separate RFC.

In a perfect world I'd agree that this would be the way to do it, however
given the lack of interest shown in this in the past I think this would be a
kind of de facto consignment to oblivion of all the other formats.  The
advantage of doing it now would be that it only requires a few words changed
here and there, rather than an entire new RFC that (most probably) no-one will
ever be motivated to write (just thinking of my own code, it'd take me about 5
minutes to add an "x509-whatever" or "pgp-whatever" entry to the SSH cert
decoding table, but a great many hours to do an RFC to specify it).  It's a
pay-me-now/pay-me-later thing, I'd rather change a sentence or two now than
have to do an entire RFC later.

The only possible ambiguity I can see with the use of X.509/OpenPGP/SPKI keys
is whether you include a single key/cert or throw in an entire WoT/cert
chain/whatever bundle, so the text would have to be explicit in saying that
only a single key/cert is present, not an arbitrary collection of stuff.  I
guess if you want to be really picky you could go on for pages and pages about
which sort of cert/key attributes need to be present and how to determine
whether they're valid for the server being connected to and how to handle
revocation checking and let's convene a subcommittee to report back on this in
six months, but since the current way of doing it is just a raw public key
with no attributes at all, I think a sentence like "Determining whether a key
or certificate is valid for its intended purpose is a local configuration
issue" would be the best way out.

Either that or just drop all foreign formats on grounds of total
incomprehensibility and no-one's really interested anyway.

Peter.