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

[Ballot comment]
I share some of Adam's concerns about compromise of the signing key. But that's an issue with the whole approach, not this document per se. I don't see a reason to hold up publication of this draft.

[Ballot comment]
[Update: I've been educated, and am a happy camper ]
For my own education -- I'd like to understand why this is specifically about drafts, and doesn't also cover RFCs. I spent some time searching, but "RFC signing" and similar brings up many results, just not relevant to the question. Is there a reason this cannot also be applied to published RFCs? Is there a pointer to what is currently done for RFCs (I feel I should know this, and have some vague recollection of having heard something about it, but cannot find / remember at the moment).

Nit:
The document says: "The IETF Secretariat generates the digital signature shortly after the Internet-Draft is posted in the repository". "shortly" is subjective -- I had to go find Section 3.2.3.3. (Signing-Time Attribute) of RFC 5845 to resolve "shortly" to "several hours or days after the time that the Internet-Draft was actually posted.".
I have no opinion if "several hours or days" is a reasonable time, but isn't what I would have guessed from "shortly".

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

[Ballot comment]
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 overhauled rather than spending the time to patch a fundamentally broken system to work with the new formats. [A high-level summary, for anyone who is interested: if any signing key (expired or not) for i-ds 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.]

That said, if we're doing this, I have a number of comments on the current document.

_______
(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 a new document when the corresponding work is undertaken.

______
(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 contents means the underlying document should be in the "Normative References" section.

_____
(5) Handling of BOMs in HTML

HTML5 has explicit handling regarding BOMs (cf. ), 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.

[Ballot comment]
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 overhauled rather than spending the time to patch a fundamentally broken system to work with the new formats. [A high-level summary, for anyone who is interested: if any signing key (expired or not) for i-ds 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.]

That said, if we're doing this, I have a number of comments on the current document.

_______
(1) Consider registering id-ct-pub

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 a new document when the corresponding work is undertaken.

______
(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 contents means the underlying document should be in the "Normative References" section.

_____
(5) Handling of BOMs in HTML

HTML5 has explicit handling regarding BOMs (cf. ), 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.

[Ballot comment]
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 overhauled rather than spending the time to patch a fundamentally broken system to work with the new formats. [A high-level summary, for anyone who is interested: if any signing key (expired or not) for i-ds 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.]

That said, if we're doing this, I have a number of comments on the current document.
_______
(1) Consider registering id-ct-pub

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 a new document when the corresponding work is undertaken.

______
(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 contents means the underlying document should be in the "Normative References" section.

_____
(5) Handling of BOMs in HTML

HTML5 has explicit handling regarding BOMs (cf. ), 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.

[Ballot comment]
For my own education -- I'd like to understand why this is specifically about drafts, and doesn't also cover RFCs. I spent some time searching, but "RFC signing" and similar brings up many results, just not relevant to the question. Is there a reason this cannot also be applied to published RFCs? Is there a pointer to what is currently done for RFCs (I feel I should know this, and have some vague recollection of having heard something about it, but cannot find / remember at the moment).

Nit:
The document says: "The IETF Secretariat generates the digital signature shortly after the Internet-Draft is posted in the repository". "shortly" is subjective -- I had to go find Section 3.2.3.3. (Signing-Time Attribute) of RFC 5845 to resolve "shortly" to "several hours or days after the time that the Internet-Draft was actually posted.".
I have no opinion if "several hours or days" is a reasonable time, but isn't what I would have guessed from "shortly".

[Ballot comment]
This whole canonicalization things seems pretty unfortunate. I feel like we're rapidly leaving the era where we have to worry about transformations in FTP. However, given that it's in the predecessor document, I won't object.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-housley-id-sig-update-02. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the current draft, the author requests the following:

"Please assign and object identifiers for id-ct-utf8TextWithCRLF in the SMI Security for S/MIME CMS Content Type registry (1.2.840.113549.1.9.16.1)."

In discussions with the author, IANA understands that a single action is requested.

In the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

the existing registration for decimal value 37 will have its reference changed to [ RFC-to-be ].

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-01-02):

From: The IESG
To: IETF-Announce
CC: alissa@cooperw.in, jimsch@augustcellars.com, draft-housley-id-sig-update@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Update to Digital Signatures on Internet-Draft Documents) to Informational RFC


The IESG has received a request from an individual submitter to consider the
following document: - 'Update to Digital Signatures on Internet-Draft
Documents'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-01-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  RFC 5485 specifies the conventions for digital signatures on
  Internet-Draft documents.  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.

  The RFC Editor recently published the first RFC that includes non-
  ASCII characters in a "text" file.  The conventions specified in RFC
  7997 were followed.  We assume that non-ASCII characters will soon
  start appearing in Internet-Drafts as well.  This document updates
  the handling of digital signatures on Internet-Draft document for
  non-ASCII characters in a "text" file.

  This document (once approved) updates RFC 5485.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-housley-id-sig-update/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-housley-id-sig-update/ballot/


No IPR declarations have been submitted directly on this I-D.