Update to Digital Signatures on Internet-Draft Documents
draft-housley-id-sig-update-03

I have the same top-level concerns about the signatures on i-ds over-promising on the guarantees they're providing as I did with potential RFC signatures. I would have preferred to see the i-d signature system deprecated or fixed rather than spending the time to patch a fundamentally broken system to work with the new formats. [A high-level summary: if any signing key (expired or not) is ever compromised, we have no path to recovery. Signatures forged with a compromised key will validate, and we will have no recourse other than a publicity campaign to inform interested parties that no signature can be trusted from that point forward.]

I cannot condone additional work on this signing system until it has some sensible means of dealing with key compromise, and am therefore balloting "ABSTAIN". The foregoing concerns have already been expressed to the document author in the context of RFC signing, so I do not expect this to be surprising.

That said, if we're publishing this anyway, I have a number of comments (as the contents of this document may have bearing on any fixed system we define in the future).

_______
(1) Consider registering id-ct-epub

If we're registering new formats based on RFC 7990 (which seems to be the impetus for this document), it would seem to be far easier to add epub (RFC 7990, section 7.4.1) at this time rather than requiring new epub format work to take care of it when that work is begun.

______
(2) Register HTML under "SMI Security for S/MIME CMS Content Type" or explain use of z39-50 OID

This definition in section 3 sticks out as exceptionally odd:

>       id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { 1 2 840 10003 5 109 3 }

Given that we don't use (e.g.) 1.2.840.10003.5.109.10 for XML or 1.2.840.10003.5.109.1 for PDF, the appearance of an OID from the 1.2.840.10003.5.109 namespace needs some kind of explanation. Alternately (and... probably preferably?), this document should probably register a value under 1.2.840.113549.1.9.16.1 instead.

_____
(3) Handling of U+FEFF mid-document

Section 4.1 says:

   A byte-order-mark (BOM) used at the beginning of a UTF8 file is not
   considered to be part of the file content.  When present, a leading
   BOM MUST NOT be processed by the digital signature algorithm.

For clarity, this should probably (a) clearly indicate that a zero-width-no-break-space appearing elsewhere in the document is not elided, and (b) indicate exactly what to do if multiple U+FEFF characters appear at the start of a document.

_____
(4) W3C XML document should be normative

Section 4.2 says:

   A robust signature generation process MAY perform canonicalization to
   ensure that the W3C guidance has been followed.

The W3C guidance in question is the document currently cited as [R20060816]. This normative reference to its procedures means the underlying document should be in the "Normative References" section.

_____
(5) Handling of BOMs in HTML

HTML5 has explicit handling regarding BOMs (cf. <https://dev.w3.org/html5/spec-preview/Overview.html#encoding-sniffing-algorithm>), so one might reasonably expect them to be added/removed/etc by HTTP servers and/or clients under certain circumstances. As a consequence, I believe that section 4.2 needs the same BOM considerations as section 4.1 (including the caveats I outline above).

_____
(6) XML reference out of date

In section 9:

   [R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler,
               and F. Yergeau, "Extensible Markup Language (XML) 1.0
               (Fourth Edition)", W3C Recommendation, 16 August 2006.
               http://www.w3.org/TR/2006/REC-xml-20060816.

This URL brings up a prominent red-box warning that the document is out of date. I believe you want to reference the 20081126 version instead. Also, all W3C specs now appear at https URLs rather than http URLs.