< draft-housley-id-sig-update-01.txt		draft-housley-id-sig-update-02.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: 5485 (once approved)
	Expires: 13 May 2018 13 November 2017		Expires: 4 June 2018 4 December 2017
	Update to Digital Signatures on Internet-Draft Documents		Update to Digital Signatures on Internet-Draft Documents
	<draft-housley-id-sig-update-01.txt>		<draft-housley-id-sig-update-02.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 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	ASCII text id-ct-asciiTextWithCRLF		ASCII text id-ct-asciiTextWithCRLF
	UTF8 text (includes non-ASCII) id-ct-utf8TextWithCRLF		UTF8 text (includes non-ASCII) id-ct-utf8TextWithCRLF
	HyperText Markup Language (HTML) id-ct-htmlWithCRLF		HyperText Markup Language (HTML) id-ct-htmlWithCRLF
	Extensible Markup Language (XML) id-ct-xml		Extensible Markup Language (XML) id-ct-xml
	Portable Document Format (PDF) id-ct-pdf		Portable Document Format (PDF) id-ct-pdf
	PostScript id-ct-postscript		PostScript id-ct-postscript
	The object identifiers associated with the content types listed above		The object identifiers associated with the content types listed above
	table are:		table are:
	id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-ct OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 }		us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 }
	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-utf8TextWithCRLF OBJECT IDENTIFIER ::= { id-ct <TBD> }
	id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }		id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { 1 2 840 10003 5 109 3 }
	id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 }		id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
	id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 }		id-ct-pdf OBJECT IDENTIFIER ::= { id-ct 29 }
	id-ct-utf8TextWithCRLF OBJECT IDENTIFIER ::= { id-ct <TBD2> }		id-ct-postscript OBJECT IDENTIFIER ::= { id-ct 30 }
	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 44 ¶		skipping to change at page 6, line 44 ¶
	ensure that the W3C guidance has been followed. This guidance says		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		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		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		and any <CR> that is not followed by <LF> are to be translated to a
	single <LF> character.		single <LF> character.
	4.3. No Canonicalization of Other File Formats		4.3. No Canonicalization of Other File Formats
	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, including PDF [PDF] and Postscript [PS],
	by the digital signature algorithm.		are treated as a simple sequence of octets 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 in
	id-ct-htmlWithCRLF in the SMI Security for S/MIME CMS Content Type		the SMI Security for S/MIME CMS Content Type registry
	registry (1.2.840.113549.1.9.16.1).		(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 5652, September 2009.		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.
			[PS] Adobe Systems Incorporated, "PostScript Language
			Reference Manual, third edition", Addison-Wesley
			Publishing Company, ISBN 0-201-37922-8, 1999.
	[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:		Information technology - ASN.1 encoding rules:
	Specification of Basic Encoding Rules (BER), Canonical		Specification of Basic Encoding Rules (BER), Canonical
	skipping to change at page 7, line 49 ¶		skipping to change at page 8, line 4 ¶
	[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		[MSG] Ramsdell, B., and S. Turner, "Secure/Multipurpose
	Internet Mail Extensions (S/MIME) Version 3.2 Message		Internet Mail Extensions (S/MIME) Version 3.2 Message
	Specification", 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.
	10. 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, Chris Newman, and Glen
	Glen Barney played a key role in implementing Internet-Draft		Barney. Glen Barney also played a key role in implementing Internet-
	signatures as specified in RFC 5485 [IDSIG].		Draft signatures as specified in RFC 5485 [IDSIG].
	Author's Address		Author's Address
	Russell Housley		Russell Housley
	Vigil Security, LLC		Vigil Security, LLC
	918 Spring Knoll Drive		918 Spring Knoll Drive
	Herndon, VA 20170		Herndon, VA 20170
	USA		USA
	EMail: housley@vigilsec.com		EMail: housley@vigilsec.com
End of changes. 14 change blocks.
	18 lines changed or deleted		24 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/