Digital Signatures on Internet-Draft Documents
RFC 5485

Note: This ballot was opened for revision 08 and is now closed.

(Ron Bonica) Yes

(Tim Polk) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Pasi Eronen) (was Discuss) No Objection

Comment (2009-01-29)
No email
send info
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.

(Cullen Jennings) No Objection

(Chris Newman) (was Discuss) No Objection

Comment (2008-12-11)
No email
send info
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.

(Mark Townsley) No Objection

(David Ward) No Objection

Comment (2008-12-10 for -)
No email
send info
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?

Magnus Westerlund No Objection

(Russ Housley) Recuse