Digital Signatures on Internet-Draft Documents
draft-housley-internet-draft-sig-file-08

[Ballot comment]
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.

[Ballot discuss]
Section 2.3: a question: would end-of-line encoding issues etc.
also affect XML files? (they might, if you e.g. download them from
ftp.ietf.org without giving the "binary" command first)

[Ballot discuss]
Section 2.3: a question: would end-of-line encoding issues etc.
also affect XML files? (they might, if you e.g. download them from
ftp.ietf.org without giving the "binary" command first)

[Ballot comment]
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.

[Ballot discuss]
This draft creates a parallel media-type namespace using OIDs, when the
IETF already has an acceptable IANA-managed media type registry.  Why
was the choice made to use a complex new opaque typing system rather
than reuse the existing human-readable type system?

[Ballot discuss]
This document has basically two parts: (A) a file format for detached
signatures for plain text (and other) files, and (B) how to use that
file format in IETF for Internet-Drafts.

Part A is simple and straight-forward; I have couple of nits (included
below), but I'm much more concerned about part B:

I guess the goal of this draft 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).

To me, it looks like cost(deploying and running the system) would be
non-trivial, and it's not clear that it actually helps with cost(legal
stuff). On the other hand, this draft omits most details of "part B",
so it's hard to reason about this without knowing the other pieces.

Some preliminary thoughts to start a discussion:

To be useful with legal stuff, you need to be able to convince others
that the signatures imply something meaningful (i.e. that a particular
Internet-Draft was posted on certain date, and the copy you have
hasn't been modified).

This would mean convincing others that (1) the signature validates
with the draft copy you have, (2) the cert included with the signature
is the cert that's supposed to be used for signing drafts (instead of
a valid cert for some other purpose), (3) the private key hasn't been
available to unauthorized parties; (4) the authorized parties have
used the private key according to well-defined process; and (5) the
well-defined process leads to the desired meaningful result.

(Note: I'm using the word "convince", not "prove" -- the latter would
be too high a standard.)

This draft addresses basically item (1), but that's the easiest.
Steps 2...5 are more difficult. It's not that difficult to operate
such a system correctly, but it's much more difficult (and costly) to
convince someone else (possibly 10 years after the fact) that you have
actually done so. Even for uses such as a company signing its own
software images to be run on its own hardware, being able to convince
others (if e.g. the software implements DRM functionality that will
protect content owned by others) can mean 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.

While this use case may not require all that complexity, it's also
clear that just signing the drafts is not enough. I could easily (and
very cheaply!) sign all Internet-Drafts using the syntax specified in
draft (OpenSSL command line tools + some Perl scripts would probably
be enough), but nobody would care because I can't convince anyone of
steps 2...5.

More specific topics/questions:

- Have approaches not involving private keys (or other secrets) been
considered? Things like publishing the hashes of Internet-Drafts (or
more likely, a hash of a file containing all the hashes) in the IETF
Journal? Or getting the draft-index-with-hashes stimestamped by some
commercial notary/timestamping entity?  Or perhaps just printing the
draft-index-with-hashes on paper once a month, getting it dated and
signed by two persons, and archiving it?

Much of the complexity about HSMs, external audits, etc. goes away if
there is no private key to protect -- and even someone violating the
written process can't easily back-date stuff.

- How does this affect the IT operations, and how much the secretariat
IT staff has been involved? AFAIK the secretariat has two sets of
servers (primary and backup) in separate geographical locations. Does
that mean two HSMs? With the same or different key? How to handle the
passphrase (that activates the HSM or decrypts the private key from
disk) -- is there staff present in these locations?  They probably
have remote power cycling -- does that continue to work as before? 
If private key+passphrase are on the disk, what does that mean for
handling of backups?

(Today, those servers probably store the www.ietf.org SSL certificate
private key and passphrase on the disk, and nobody is very worried
about it -- we trust that the secretariat staff is competent. But
there's no need to convince someone else later (possibly 10 years
later) that the www.ietf.org private key has always been handled
properly.)

- To me, it seems signing all drafts during the posting process would
be much more complex than signing all new drafts, say, once a
week. The latter would have less issues with primary/backup server
failover, and could include manual steps such as entering a passphrase
or smart card, or recording something in a paper-based log book. It
would also take the HSM (and everything related to it) off from the
critical path for draft submissions tools etc.

Nits about the signature format specifically:

- Section 2 says "documents from IETF working groups will have "ietf-"
followed by the working group abbreviation"; strictly speaking, you
can adopt a draft as WG document without changing the file name (but
fortunately most WG chairs don't know that -- there are currently only
five active WG drafts that don't start with "draft-ietf-" :-).

- Section 2.2 seems to assume that Internet-Drafts contain only ASCII.
While this is true in theory, it's not clear what the canonicalization
process outputs when it encounters a non-ASCII character. Currently,
there are five active Internet-Drafts that contain non-ASCII
characters (and interestingly enough, also 27 RFCs!).

- Section 2.3: a question: would end-of-line encoding issues etc.
also affect XML files? (they might, if you e.g. download them from
ftp.ietf.org without giving the "binary" command first)

- Appendix A should say that "" is the name of the
file that has been canonicalized as described in Section 2.2 (not the
Internet-Draft file as downloaded from www.ietf.org -- that's often
not canonicalized).

[Ballot comment]
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?

[Ballot comment]
This draft left me wondering about much of the harder operational issues.

Several places it refers to the IETF Secretariat running this. It seems like it might be more appropriate to have the RFC PUblisher to do it or the RFC Production Center.

What certificate will be used to sign this stuff, how will people get it or validate it.

How should the trust control the private keys - particularly in the case of transitioning the operation of the signing from one contractor to another.

Initial recommendation on keys size and crypto algorithms

Document Shepherd Write-Up for draft-housley-internet-draft-sig-file-06.txt

(1.a)  Who is the Document Shepherd for this document?  Has the
  Document Shepherd personally reviewed this version of the document
  and, in particular, does he or she believe this version is ready
  for forwarding to the IESG for publication?

  Russ Housley is the Document Shepherd and author.


(1.b)  Has the document had adequate review both from key members of
  the interested community and others?  Does the Document Shepherd
  have any concerns about the depth or breadth of the reviews that
  have been performed?

  No concerns.

  The document is intended for publication as an Informational RFC.
  It has been reviewed by several community members, and several
  people associated with different CMS implementations have
  confirmed their implementations can handle the CMS profile.


(1.c)  Does the Document Shepherd have concerns that the document
  needs more review from a particular or broader perspective, e.g.,
  security, operational complexity, someone familiar with AAA,
  internationalization or XML?

  No concerns.


(1.d)  Does the Document Shepherd have any specific concerns or
  issues with this document that the Responsible Area Director
  and/or the IESG should be aware of?  For example, perhaps he or
  she is uncomfortable with certain parts of the document, or has
  concerns whether there really is a need for it.  In any event, if
  the interested community has discussed those issues and has
  indicated that it still wishes to advance the document, detail
  those concerns here.

  No concerns.


(1.e)  How solid is the consensus of the interested community behind
  this document?  Does it represent the strong concurrence of a few
  individuals, with others being silent, or does the interested
  community as a whole understand and agree with it?

  No concerns; however,  I suggest an IETF Last Call to ensure that
  all community members have an opportunity to review the document.


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarise the areas of conflict in
  separate email messages to the Responsible Area Director.  (It
  should be in a separate email because this questionnaire is
  entered into the ID Tracker.)

  No.


(1.g)  Has the Document Shepherd personally verified that the
  document satisfies all ID nits?  (See
  http://www.ietf.org/ID-Checklist.html and
  http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
  enough; this check needs to be thorough.  Has the document met all
  formal review criteria it needs to, such as the MIB Doctor, media
  type and URI type reviews?

  There is no need for any formal review from the MIB Doctors or
  any other such group.

  No problems with ID-Checklist were noticed.  ID-Nits did flag two
  errors.  ID-Nits reports:

    ** There are 7 instances of too long lines in the document, the
        longest one being 4 characters in excess of 72.

    ** There are 3 instances of lines with non-RFC2606-compliant
        FQDNs in the document.

    The first error has detected a very minor problem that is easily
    resoled along with any IETF Last Call comments that come up.

    I cannot find any FQDNs that raise concern.  I suspect that the
    error is being triggered by the reference to the OpenSSL web site.


(1.h)  Has the document split its references into normative and
  informative?  Are there normative references to documents that are
  not ready for advancement or are otherwise in an unclear state?
  If such normative references exist, what is the strategy for their
  completion?  Are there normative references that are downward
  references, as described in [RFC3967]?  If so, list these downward
  references to support the Area Director in the Last Call procedure
  for them [RFC3967].

  References are split.


(1.i)  Has the Document Shepherd verified that the document IANA
  consideration section exists and is consistent with the body of
  the document?  If the document specifies protocol extensions, are
  reservations requested in appropriate IANA registries?  Are the
  IANA registries clearly identified?  If the document creates a new
  registry, does it define the proposed initial contents of the
  registry and an allocation procedure for future registrations?
  Does it suggested a reasonable name for the new registry?  See
  [RFC5226].  If the document describes an Expert Review process has
  the Shepherd conferred with the Responsible Area Director so that
  the IESG can appoint the needed Expert during the IESG Evaluation?

  No IANA actions are required.


(1.j)  Has the Document Shepherd verified that sections of the
  document that are written in a formal language, such as XML code,
  BNF rules, MIB definitions, etc., validate correctly in an
  automated checker?

  No formal language is used.


(1.k)  The IESG approval announcement includes a Document
  Announcement Write-Up.  Please provide such a Document
  Announcement Writeup?  Recent examples can be found in the
  "Action" announcements for approved documents.  The approval
  announcement contains the following sections:

  Technical Summary

    This document  specifies the conventions for digital signatures on
    Internet-Drafts.  The Cryptographic Message Syntax (CMS) is used
    to create a detached signature, which is stored in a separate
    companion file so that no existing utilities are impacted by the
    addition of the digital signature.

  Working Group Summary

    This document is not the product of any IETF working group.
    However, the S/MIME Working Group was asked to comment, and the
    comments that were received were all resolved.

  Document Quality

    OpenSSL was used to generate a sample signature file.  OpenSSL and
    at least one other CMS implementation were able to validate the
    signature.