Digital Signatures on Internet-Draft Documents
RFC 5485
Yes
No Objection
Recuse
Note: This ballot was opened for revision 08 and is now closed.
(Ron Bonica; former steering group member) Yes
(Tim Polk; former steering group member) Yes
(Chris Newman; former steering group member) (was Discuss) No Objection
It appears that CMS introduced a parallel media-type namespace using OIDs, when the IETF already has an acceptable IANA-managed media type registry. While it does not appear to be fixable for this document, the fact these two things are different is a design flaw that should be fixed. Options to fix it would seem to be: 1. Change CMS so it can use an UTF8String for the media type so the IANA registry for media types and parameters can be directly used. 2. Change the IANA registry for media types so every media type and media type parameter gets an OID assigned automatically by IANA (similar to the way the charset registry assigns MIB numbers when a charset is registered). Obviously, I'd find 1 a better solution since it's less costly in terms of process and IANA effort.
(Cullen Jennings; former steering group member) No Objection
(David Ward; former steering group member) No Objection
This scheme seems to be aimed at giving the reader some assurance that the text isn't changing randomly out from under them. It doesn't seem to give the author any assurance that what was submitted hadn't been altered. I suppose diff is to take care of that?
(Jari Arkko; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Pasi Eronen; former steering group member) (was Discuss) No Objection
This document has basically two parts: (A) a file format for detached signatures for plain text (and other) files, and (B) some ideas about how to use that file format in IETF for Internet-Drafts. Part A is simple and straight-forward. However, part B doesn't actually contain much, and many details need to be worked out before this can be deployed in a meaningful way. Those details probably do not belong in this draft. However, I hope the community is given an opportunity to comment them before a decision to deploy this is made. I guess the goal of deploying this is that cost(deploying and running new system) + cost(legal stuff with new system) is smaller than cost(legal stuff with current system). (where "legal stuff" refers to e.g. disputes between two companies where IETF subpoaned, and "cost" refers to money/work by IETF/IASA/ISOC/secretariat). The missing details -- how to actually operate this in a way that convinces others that the signatures imply something meaningful -- will significantly affect the cost(deploying and running new system). Just signing drafts is not enough -- I could easily (and very cheaply!) sign all Internet-Drafts using the format in this document (OpenSSL command line tools + some Perl scripts would probably be enough), but probably nobody would care. Folks would suspect that I'm either malicious (intentionally producing signatures with dates in the past), or much more probably, careless (someone else has had access to the private key and/or the system I use for creating the signatures). Probably folks trust that the IETF secretariat is not malicious, but actually demonstrating that they're also careful isn't simple. For certification authorities, this means things like the "four eyes principle" (every action involves two persons), lots of documentation (and I mean a *lot*), regular external audits, hardware security modules, highly secure rooms, videotaped key generation ceremonies, and so on. Certainly we don't need all that for just signing drafts, but without any processes, the signatures won't be convincing.
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) Recuse