< draft-housley-id-sig-update-00.txt		draft-housley-id-sig-update-01.txt >
	INTERNET-DRAFT R. Housley		INTERNET-DRAFT R. Housley
	Intended Status: Informational Vigil Security		Intended Status: Informational Vigil Security
	Updates RFC 5485 (once approved)		Updates: RFC 5485 (once approved)
	Expires: 4 April 2018 4 October 2017		Expires: 13 May 2018 13 November 2017
	Update to Digital Signatures on Internet-Draft Documents		Update to Digital Signatures on Internet-Draft Documents
	<draft-housley-id-sig-update-00.txt>		<draft-housley-id-sig-update-01.txt>
	Abstract		Abstract
	RFC 5485 specifies the conventions for digital signatures on		RFC 5485 specifies the conventions for digital signatures on
	Internet-Draft documents. The Cryptographic Message Syntax (CMS) is		Internet-Draft documents. The Cryptographic Message Syntax (CMS) is
	used to create a detached signature, which is stored in a separate		used to create a detached signature, which is stored in a separate
	companion file so that no existing utilities are impacted by the		companion file so that no existing utilities are impacted by the
	addition of the digital signature.		addition of the digital signature.
	The RFC Editor recently published the first RFC that includes non-		The RFC Editor recently published the first RFC that includes non-
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		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 . . . . . . . . . . . . . . . . . . . . . 6
			6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
			7. Deployment and Operational Considerations . . . . . . . . . . 7
			8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
			9. Informative References . . . . . . . . . . . . . . . . . . . . 7
			10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	RFC 5485 [IDSIG] specifies the conventions for digital signatures on		RFC 5485 [IDSIG] specifies the conventions for digital signatures on
	Internet-Draft documents. The Cryptographic Message Syntax (CMS)		Internet-Draft documents. The Cryptographic Message Syntax (CMS)
	[CMS] is used to create a detached signature, which is stored in a		[CMS] is used to create a detached signature, which is stored in a
	separate companion file so that no existing utilities are impacted by		separate companion file so that no existing utilities are impacted by
	the addition of the digital signature.		the addition of the digital signature.
	The RFC Editor recently published the first RFC that includes non-		The RFC Editor recently published the first RFC that includes non-
	ASCII characters in a "text" file. The conventions specified in RFC		ASCII characters in a "text" file. The conventions specified in RFC
	skipping to change at page 4, line 44 ¶		skipping to change at page 5, line 21 ¶
	id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 }		id-ct-asciiTextWithCRLF OBJECT IDENTIFIER ::= { id-ct 27 }
	id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct <TBD1> }		id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct <TBD1> }
	id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }		id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
	id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 }		id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 }
	id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 }		id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 }
	id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct <TBD2> }		id-ct-utf8TextWithCRLF OBJECT IDENTIFIER ::= { id-ct <TBD2> }
	4. Need for Canonicalization		4. Need for Canonicalization
	In general, the content of an Internet-Draft is treated like a single		In general, the content of an Internet-Draft is treated like a single
	octet string for the generation of the digital signature.		octet string for the generation of the digital signature.
	Unfortunately, the text and HTML files require canonicalization to		Unfortunately, the text and HTML files require canonicalization to
	avoid signature validation problems. The primary concern is the		avoid signature validation problems. The primary concern is the
	manner in which different operating systems indicate the end of a		manner in which different operating systems indicate the end of a
	line of text. Some systems use a single new-line character, other		line of text. Some systems use a single new-line character, other
	systems use the combination of the carriage-return character followed		systems use the combination of the carriage-return character followed
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 51 ¶
	No canonicalization is needed for file formats currently used or		No canonicalization is needed for file formats currently used or
	planned for Internet-Drafts other than ASCII, UTF8, HTML, and XML		planned for Internet-Drafts other than ASCII, UTF8, HTML, and XML
	files. Other file formats are treated as a simple sequence of octets		files. Other file formats are treated as a simple sequence of octets
	by the digital signature algorithm.		by the digital signature algorithm.
	5. IANA Considerations		5. IANA Considerations
	Please assign and object identifiers for id-ct-utf8TextWithCRLF and		Please assign and object identifiers for id-ct-utf8TextWithCRLF and
	id-ct-htmlWithCRLF in the SMI Security for S/MIME CMS Content Type		id-ct-htmlWithCRLF in the SMI Security for S/MIME CMS Content Type
	registry.		registry (1.2.840.113549.1.9.16.1).
	6. Security Considerations		6. Security Considerations
	The security consideration in RFC 5485 [IDSIG] are unchanged.		The security consideration in RFC 5485 [IDSIG] are unchanged.
	7. Deployment and Operational Considerations		7. Deployment and Operational Considerations
	The deployment consideration in RFC 5485 [IDSIG] are unchanged.		The deployment consideration in RFC 5485 [IDSIG] are unchanged.
	8. Normative References		8. Normative References
	[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",		[CMS] Housley, R., "Cryptographic Message Syntax (CMS)",
	RFC 3852, July 2004.		RFC 5652, September 2009.
	[IDSIG] Housley, R., "Digital Signatures on Internet-Draft		[IDSIG] Housley, R., "Digital Signatures on Internet-Draft
	Documents", RFC 5485, March 2009.		Documents", RFC 5485, March 2009.
	[PDF] ISO, "Portable document format -- Part 1: PDF 1.7",		[PDF] ISO, "Portable document format -- Part 1: PDF 1.7",
	ISO 32000-1, 2008.		ISO 32000-1, 2008.
	[STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate		[STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,		[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
	Information technology - Abstract Syntax Notation One		Information technology - Abstract Syntax Notation One
	(ASN.1): Specification of basic notation.		(ASN.1): Specification of basic notation.
	[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,		[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
	Information technology - ASN.1 encoding rules: Specification		Information technology - ASN.1 encoding rules:
	of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)		Specification of Basic Encoding Rules (BER), Canonical
	and Distinguished Encoding Rules (DER).		Encoding Rules (CER) and Distinguished Encoding Rules
			(DER).
	11. Informative References		9. Informative References
	[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol",		[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol",
	STD 9, RFC 959, October 1985.		STD 9, RFC 959, October 1985.
	[MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail		[MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose
	Extensions (S/MIME) Version 3.2 Message Specification",		Internet Mail Extensions (S/MIME) Version 3.2 Message
	RFC 5751, January 2010.		Specification", RFC 5751, January 2010.
	[R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler,		[R20060816] Bray, T., J. Paoli, C. M. Sperberg-McQueen, E. Maler,
	and F. Yergeau, "Extensible Markup Language (XML) 1.0		and F. Yergeau, "Extensible Markup Language (XML) 1.0
	(Fourth Edition)", W3C Recommendation, 16 August 2006.		(Fourth Edition)", W3C Recommendation, 16 August 2006.
	http://www.w3.org/TR/2006/REC-xml-20060816.		http://www.w3.org/TR/2006/REC-xml-20060816.
	[RFCED] Flanagan, H., "The Use of Non-ASCII Characters in RFCs",		[RFCED] Flanagan, H., "The Use of Non-ASCII Characters in RFCs",
	RFC 7997, December 2016.		RFC 7997, December 2016.
	[RFCSERIES] Flanagan, H., and N. Brownlee, "RFC Series Format		[RFCSERIES] Flanagan, H., and N. Brownlee, "RFC Series Format
	Requirements and Future Development", RFC 6949, May 2013.		Requirements and Future Development", RFC 6949, May 2013.
	[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol		[TELNET] Postel, J. and J. Reynolds, "Telnet Protocol
	Specification", STD 8, RFC 854, May 1983.		Specification", STD 8, RFC 854, May 1983.
	[UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for		[UFNI] J. Klensin, J. and M. Padlipsky, "Unicode Format for
	Network Interchange", RFC 5198, March 2008.		Network Interchange", RFC 5198, March 2008.
	12. Acknowledgements		10. Acknowledgements
	The idea for the Internet-Draft signature file came from a discussion		The idea for the Internet-Draft signature file came from a discussion
	with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful		with Scott Bradner at IETF 69 in Chicago, IL, USA. Many helpful
	suggestions came from Jim Schaad, Pasi Eronen, and Chris Newman.		suggestions came from Jim Schaad, Pasi Eronen, and Chris Newman.
	Glen Barney played a key role in implementing Internet-Draft		Glen Barney played a key role in implementing Internet-Draft
	signatures as specified in RFC 5485 [IDSIG].		signatures as specified in RFC 5485 [IDSIG].
	Author's Address		Author's Address
	Russell Housley		Russell Housley
End of changes. 10 change blocks.
	16 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/