Internet DRAFT - draft-housley-id-sig-update
draft-housley-id-sig-update
INTERNET-DRAFT R. Housley
Intended Status: Informational Vigil Security
Updates: 5485 (once approved)
Expires: 18 July 2018 18 January 2018
Update to Digital Signatures on Internet-Draft Documents
<draft-housley-id-sig-update-03.txt>
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
Housley [Page 1]
INTERNET-DRAFT January 2018
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Detached Signature Files . . . . . . . . . . . . . . . . . . . 3
3. Additional Content Types . . . . . . . . . . . . . . . . . . . 4
4. Need for Canonicalization . . . . . . . . . . . . . . . . . . 5
4.1. ASCII, UTF8, and HTML File Canonicalization . . . . . . . 5
4.2. XML File Canonicalization . . . . . . . . . . . . . . . . 6
4.3. No Canonicalization of Other File Formats . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Deployment and Operational Considerations . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
RFC 5485 [IDSIG] specifies the conventions for digital signatures on
Internet-Draft documents. The Cryptographic Message Syntax (CMS)
[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 [RFCED] 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 [IDSIG], which
contains the conventions that have been used by IETF Secretariat to
digitally sign Internet-Drafts for the past few years. The IETF
Secretariat generates the digital signature shortly after the
Housley [Page 2]
INTERNET-DRAFT January 2018
Internet-Draft is posted in the repository.
The digital signature allows anyone to confirm that the contents of
the Internet-Draft have not been altered since the time that the
document was signed.
The digital signature is intended to provide a straightforward way
for anyone to determine whether a particular file contains the
Internet-Draft that was made available by the IETF Secretariat. The
signing-time associated with the signature provides the wall clock
time at which the signature was generate; it is not intended to
provide a trusted timestamp.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [STDWORDS].
1.2. ASN.1
The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is
a formal notation used for describing data protocols, regardless of
the programming language used by the implementation. Encoding rules
describe how the values defined in ASN.1 will be represented for
transmission. The Basic Encoding Rules (BER) [X.690] are the most
widely employed rule set, but they offer more than one way to
represent data structures. For example, definite length encoding and
indefinite length encoding are supported. This flexibility is not
desirable when digital signatures are used. As a result, the
Distinguished Encoding Rules (DER) [X.690] were invented. DER is a
subset of BER that ensures a single way to represent a given value.
For example, DER always employs definite length encoding.
2. Detached Signature Files
All Internet-Draft file names begin with "draft-". The next portion
of the file name depends on the source of the document. For example,
documents from IETF working groups usually have "ietf-" followed by
the working group abbreviation, and this is followed by a string that
helps people figure out the subject of the document.
All Internet-Draft file names end with a hyphen followed by a two
digit version number and a suffix. The suffix indicates the type of
file. For example, a text file will have a suffix of ".txt". Today,
plain text files are the most common, but the RFC Editor has
announced plans to make use of other formats [RFCSERIES]. Each file
format employs a different suffix.
Housley [Page 3]
INTERNET-DRAFT January 2018
Going forward, one cannot assume that a text file with a suffix of
".txt" will contain only ASCII characters.
The companion signature file has exactly the same file name as the
RFC or Internet-Draft, except that ".p7s" is added to the end. This
file name suffix conforms to the conventions in RFC 5751 [MSG]. Here
are a few example names:
Internet-Draft: draft-ietf-example-widgets-03.txt
Signature File: draft-ietf-example-widgets-03.txt.p7s
Internet-Draft: draft-ietf-example-widgets-03.pdf
Signature File: draft-ietf-example-widgets-03.pdf.p7s
Internet-Draft: draft-housley-internet-draft-sig-file-00.txt
Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s
3. Additional Content Types
The CMS is used to construct the detached signatures for Internet-
Drafts. The CMS ContentInfo content type MUST always be present, and
it MUST encapsulate the CMS SignedData content type. Since a
detached signature is being created, the CMS SignedData content type
MUST NOT encapsulate the Internet-Draft. The CMS detached signature
is summarized in RFC 5485 [IDSIG].
The SignedData.SignerInfo.EncapsulatedContentInfo.eContentType value
MUST identify the format of the Internet-Draft that is being signed.
Section 5 of RFC 5485 [IDSIG] lists the file formats and the
associated content type. This document expands that list as follows:
File Format Content Type
----------- ------------
ASCII text id-ct-asciiTextWithCRLF
UTF8 text (includes non-ASCII) id-ct-utf8TextWithCRLF
HyperText Markup Language (HTML) id-ct-htmlWithCRLF
EPUB id-ct-epub
Extensible Markup Language (XML) id-ct-xml
Portable Document Format (PDF) id-ct-pdf
PostScript id-ct-postscript
Housley [Page 4]
INTERNET-DRAFT January 2018
The object identifiers associated with the content types listed above
table are:
id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 }
id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 }
id-ct-utf8TextWithCRLF OBJECT IDENTIFIER ::= { id-ct 37 }
id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct TBD }
id-ct-epub OBJECT IDENTIFIER ::= { id-ct TBD }
id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 }
id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 }
4. Need for Canonicalization
In general, the content of an Internet-Draft is treated like a single
octet string for the generation of the digital signature.
Unfortunately, the text and HTML files require canonicalization to
avoid signature validation problems. The primary concern is the
manner in which different operating systems indicate the end of a
line of text. Some systems use a single new-line character, other
systems use the combination of the carriage-return character followed
by a line-feed character, and other systems use fixed-length records
padded with space characters. For the digital signature to validate
properly, a single convention must be employed.
4.1. ASCII, UTF8, and HTML File Canonicalization
The canonicalization procedure follows the conventions used for text
files in the File Transfer Protocol (FTP) [FTP]. Such files must be
supported by FTP implementations, so code reuse seems likely.
The canonicalization procedure converts the data from its internal
character representation to the standard 8-bit NVT-ASCII
representation (see TELNET [TELNET]). In accordance with the NVT
standard, the <CRLF> sequence MUST be used to denote the end of a
line of text. Using the standard NVT-ASCII representation means that
data MUST be interpreted as 8-bit bytes.
Trailing space characters MUST NOT appear on a line of text. That
is, the space character must not be followed by the <CRLF> sequence.
Housley [Page 5]
INTERNET-DRAFT January 2018
Thus, a blank line is represented solely by the <CRLF> sequence.
The form-feed nonprintable character (0x0C) is expected in Internet-
Drafts. Other non-printable characters, such as tab and backspace,
are not expected, but they do occur. Non-printable or non-ASCII
characters (ones outside the range 0x20 to 0x7E) MUST NOT be changed
in any way not covered by the rules for end-of-line handling in the
previous paragraph.
Trailing blank lines MUST NOT appear at the end of the file. That
is, the file must not end with multiple consecutive <CRLF> sequences.
In some environments, a byte-order-mark (BOM) (U+FEFF) is used at the
beginning of a file to indicate that it contains non-ASCII
characters. In UTF8 or HTML files, a BOM at the beginning of the
file is not considered to be part of the file content. One or more
consecutive leading byte-order-marks, if present, MUST NOT be
processed by the digital signature algorithm.
Any end-of-file marker used by an operating system is not considered
to be part of the file content. When present, such end-of-file
markers MUST NOT be processed by the digital signature algorithm.
Note: This text file canonicalization procedure is consistent with
the NVT-ASCII definition offered in Appendix B of RFC 5198 [UFNI].
4.2. XML File Canonicalization
Utilities that produce XML files are expected to follow the guidance
provided by the World Wide Web Consortium (W3C) in Section 2.11 of
[R20081126]. If this guidance is followed, no canonicalization is
needed.
A robust signature generation process MAY perform canonicalization to
ensure that the W3C guidance has been followed. This guidance says
that a <LF> character MUST be used to denote the end of a line of
text within a XML file. Therefore, any two-character <CRLF> sequence
and any <CR> that is not followed by <LF> are to be translated to a
single <LF> character.
4.3. No Canonicalization of Other File Formats
No canonicalization is needed for file formats currently used or
planned for Internet-Drafts other than ASCII, UTF8, HTML, and XML
files. Other file formats, including PDF [PDF], Postscript [PS], and
EPUB [EPUB] are treated as a simple sequence of octets by the digital
signature algorithm.
Housley [Page 6]
INTERNET-DRAFT January 2018
5. IANA Considerations
The IANA is requested to register object identifiers for three
content types in the SMI Security for S/MIME CMS Content Type
registry (1.2.840.113549.1.9.16.1) as follows:
Name OID Specification
-----------------------------------------------------------------
id-ct-utf8TextWithCRLF 1.2.840.113549.1.9.16.1.37 [THISRFC]
id-ct-htmlWithCRLF 1.2.840.113549.1.9.16.1.TBD [THISRFC]
id-ct-epub 1.2.840.113549.1.9.16.1.TBD [THISRFC]
6. Security Considerations
The security consideration in RFC 5485 [IDSIG] are unchanged.
7. Deployment and Operational Considerations
The deployment consideration in RFC 5485 [IDSIG] are unchanged.
8. Normative References
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 5652, September 2009.
[EPUB] International Digital Publishing Forum, "EPUB Content
Documents 3.1", 5 January 2017.
http://www.idpf.org/epub/31/spec/epub-contentdocs.html.
[IDSIG] Housley, R., "Digital Signatures on Internet-Draft
Documents", RFC 5485, March 2009.
[PDF] ISO, "Portable document format -- Part 1: PDF 1.7",
ISO 32000-1, 2008.
[PS] Adobe Systems Incorporated, "PostScript Language
Reference Manual, third edition", Addison-Wesley
Publishing Company, ISBN 0-201-37922-8, 1999.
[R20081126] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler,
and F. Yergeau, "Extensible Markup Language (XML) 1.0
(Fifth Edition)", W3C Recommendation, 26 November 2008.
https://www.w3.org/TR/2008/REC-xml-20081126/.
[STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Housley [Page 7]
INTERNET-DRAFT January 2018
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation.
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
9. Informative References
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose
Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFCED] Flanagan, H., "The Use of Non-ASCII Characters in RFCs",
RFC 7997, December 2016.
[RFCSERIES] Flanagan, H., and N. Brownlee, "RFC Series Format
Requirements and Future Development", RFC 6949, May 2013.
[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
[UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for
Network Interchange", RFC 5198, March 2008.
10. Acknowledgements
The idea for the Internet-Draft signature file came from a discussion
with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful
suggestions came from Jim Schaad, Pasi Eronen, Chris Newman, and Glen
Barney. Glen Barney also played a key role in implementing Internet-
Draft signatures as specified in RFC 5485 [IDSIG].
Author's Address
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Housley [Page 8]
