< draft-housley-rfc-and-id-signatures-00.txt		draft-housley-rfc-and-id-signatures-01.txt >
	INTERNET-DRAFT R. Housley		INTERNET-DRAFT R. Housley
	Intended Status: Informational Vigil Security		Intended Status: Informational Vigil Security
	Obsoletes RFC 5485 (once approved)		Obsoletes RFC 5485 (once approved)
	Expires: 25 August 2016 23 February 2016		Expires: 26 August 2016 24 February 2016
	Digital Signatures on RFC and Internet-Draft Documents		Digital Signatures on RFC and Internet-Draft Documents
	<draft-housley-rfc-and-id-signatures-00.txt>		<draft-housley-rfc-and-id-signatures-01.txt>
	Abstract		Abstract
	This document specifies the conventions for digital signatures on		This document specifies the conventions for digital signatures on
	RFCs and Internet-Draft documents. For most file types, the		RFCs and Internet-Draft documents. For Internet-Drafts, the
	Cryptographic Message Syntax (CMS) is used to create a detached		Cryptographic Message Syntax (CMS) is used to create a detached
	signature, which is stored in a separate companion file so that no		signature, which is stored in a separate companion file so that no
	existing utilities are impacted by the addition of the digital		existing utilities are impacted by the addition of the digital
	signature. For Portable Document Format (PDF) files types, embedded		signature. For RFCs, an embedded digital signature is included in
	signatures are supported.		Portable Document Format (PDF) files types in addition to the
			detached signature in a separate companion file.
	This document (once approved) obsoletes RFC 5485.		This document (once approved) obsoletes RFC 5485.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 25 August 2016.		This Internet-Draft will expire on 26 August 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	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.
	1. Introduction		1. Introduction
	This document specifies the conventions for storing a digital		This document specifies the conventions for digital signatures on
	signature on RFC and Internet-Draft documents. For most file types,		RFCs and Internet-Draft documents. For Internet-Drafts, the
	the Cryptographic Message Syntax (CMS) [CMS] is used to create a		Cryptographic Message Syntax (CMS) [CMS] is used to create a detached
	detached signature, which is stored in a separate companion file so		signature, which is stored in a separate companion file so that no
	that no existing utilities are impacted by the addition of the		existing utilities are impacted by the addition of the digital
	digital signature. For Portable Document Format (PDF) files types,		signature. For RFCs, an embedded digital signature is included in
	embedded signatures are supported.		Portable Document Format (PDF) [PDF] files types in addition to the
			detached signature in a separate companion file.
	This document (once approved) obsoletes RFC 5485 [RFC5485], which		This document (once approved) obsoletes RFC 5485 [IDSIG], which
	contains the conventions that have been used by IETF Secretariat to		contains the conventions that have been used by IETF Secretariat to
	digitally sign Internet-Drafts for the past few years.		digitally sign Internet-Drafts for the past few years.
	The digital signature allows anyone to confirm that the contents of		The digital signature allows anyone to confirm that the contents of
	the RFC or Internet-Draft have not been altered since the time that		the RFC or Internet-Draft have not been altered since the time that
	the document was signed.		the document was signed.
	For RFCs, the RFC Production Center [RFCED] will generate the digital		For RFCs, the RFC Production Center [RFCED] will generate the digital
	signature as the final step before passing the completed documents to		signature as the final step before passing the completed documents to
	the RFC Publisher.		the RFC Publisher.
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 22 ¶
	widely employed rule set, but they offer more than one way to		widely employed rule set, but they offer more than one way to
	represent data structures. For example, definite length encoding and		represent data structures. For example, definite length encoding and
	indefinite length encoding are supported. This flexibility is not		indefinite length encoding are supported. This flexibility is not
	desirable when digital signatures are used. As a result, the		desirable when digital signatures are used. As a result, the
	Distinguished Encoding Rules (DER) [X.690] were invented. DER is a		Distinguished Encoding Rules (DER) [X.690] were invented. DER is a
	subset of BER that ensures a single way to represent a given value.		subset of BER that ensures a single way to represent a given value.
	For example, DER always employs definite length encoding.		For example, DER always employs definite length encoding.
	2. Detached Signature Files		2. Detached Signature Files
	PDF files types accommodate embedded signatures, but other file		Detached digital signature files are created, and the name of the
	formats do not. All other file types are digitally signed by		file directly identifies the RFC or Internet-Draft that is signed.
	producing a detached signature file.
	All RFC file names begin with "rfc". The next portion of the file		All RFC file names begin with "rfc". The next portion of the file
	name contains a unique integer assigned by the RFC Production Center.		name contains a unique integer assigned by the RFC Production Center.
	For example, rfc20.txt contains a document produced in October 1969.		For example, rfc20.txt contains a document produced in October 1969.
	Some repositories contain this same document with a file name of		Some repositories contain this same document with a file name of
	rfc0020.txt.		rfc0020.txt.
	All Internet-Draft file names begin with "draft-". The next portion		All Internet-Draft file names begin with "draft-". The next portion
	of the file name depends on the source of the document. For example,		of the file name depends on the source of the document. For example,
	documents from IETF working groups usually have "ietf-" followed by		documents from IETF working groups usually have "ietf-" followed by
	skipping to change at page 3, line 49 ¶		skipping to change at page 4, line 4 ¶
	of other formats [RFCSERIES]. Each file format employs a different		of other formats [RFCSERIES]. Each file format employs a different
	suffix.		suffix.
	The companion signature file has exactly the same file name as the		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		RFC or Internet-Draft, except that ".p7s" is added to the end. This
	file name suffix conforms to the conventions in [MSG]. Here are a		file name suffix conforms to the conventions in [MSG]. Here are a
	few example names:		few example names:
	RFC: rfc8765.txt		RFC: rfc8765.txt
	Signature File: rfc8765.txt.p7s		Signature File: rfc8765.txt.p7s
	RFC: rfc8765.xml		RFC: rfc8765.xml
	Signature File: rfc8765.xml.p7s		Signature File: rfc8765.xml.p7s
			RFC: rfc8765.pdf
			Signature File: rfc8765.pdf.p7s
	RFC: rfc8765.html		RFC: rfc8765.html
	Signature File: rfc8765.html.p7s		Signature File: rfc8765.html.p7s
	Internet-Draft: draft-ietf-example-widgets-03.txt		Internet-Draft: draft-ietf-example-widgets-03.txt
	Signature File: draft-ietf-example-widgets-03.txt.p7s		Signature File: draft-ietf-example-widgets-03.txt.p7s
	Internet-Draft: draft-ietf-example-widgets-03.ps		Internet-Draft: draft-ietf-example-widgets-03.ps
	Signature File: draft-ietf-example-widgets-03.ps.p7s		Signature File: draft-ietf-example-widgets-03.ps.p7s
	Internet-Draft: draft-housley-internet-draft-sig-file-00.txt		Internet-Draft: draft-housley-internet-draft-sig-file-00.txt
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 45 ¶
	2.4. No Canonicalization of Other File Formats		2.4. 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 RFCs and Internet-Drafts other than plain text files and		planned for RFCs and Internet-Drafts other than plain text files and
	XML files. Other file formats are treated as a simple sequence of		XML files. Other file formats are treated as a simple sequence of
	octets by the digital signature algorithm.		octets by the digital signature algorithm.
	3. Signed PDF Files		3. Signed PDF Files
	PDF [PDF] has supported digital signatures since PDF 1.2, and the		PDF [PDF] has supported digital signatures since PDF 1.2. The
	signature covers the document content, the visual presentation, and		embedded signature covers the document content and embedded content.
	embedded content. The RFC Editor plans to use this feature to have		The RFC Editor plans to use this feature to include the XML that was
	the XML that was used to produce the PDF covered by the signature.		used to produce the PDF covered by the signature. Authors of
	Authors of Internet-Drafts might do this as well, but they are not		Internet-Drafts might do this as well, but they are not required to
	required to do so.		do so.
			The IETF Secretariat will generate detached signature files for
			Internet-Drafts that are posted in PDF format. If an author has
			embedded a digital signature in the PDF file before posting it, then
			the author's signature will remain in the PDF file.
			The RFC Production Center will embedded a digital signature in the
			PDF file and also generate a detached signature file for RFCs before
			passing them to the RFC Publisher for posting.
	4. CMS Profile		4. CMS Profile
	The CMS is used to construct the detached signatures for RFCs and		The CMS is used to construct the detached signatures for RFCs and
	Internet-Drafts. The CMS ContentInfo content type MUST always be		Internet-Drafts. The CMS ContentInfo content type MUST always be
	present, and it MUST encapsulate the CMS SignedData content type.		present, and it MUST encapsulate the CMS SignedData content type.
	Since a detached signature is being created, the CMS SignedData		Since a detached signature is being created, the CMS SignedData
	content type MUST NOT encapsulate the RFC or Internet-Draft. The CMS		content type MUST NOT encapsulate the RFC or Internet-Draft. The CMS
	detached signature is summarized by:		detached signature is summarized by:
	skipping to change at page 8, line 34 ¶		skipping to change at page 8, line 49 ¶
	content. The signedAttrs are optional in the CMS, but		content. The signedAttrs are optional in the CMS, but
	signedAttrs is required by this specification. The SET OF		signedAttrs is required by this specification. The SET OF
	Attribute must be encoded with the distinguished encoding rules		Attribute must be encoded with the distinguished encoding rules
	(DER) [X.690]. Section 4.2.3 of this specification lists the		(DER) [X.690]. Section 4.2.3 of this specification lists the
	signed attributes that MUST be included in the collection.		signed attributes that MUST be included in the collection.
	Other signed attributes MAY also be included.		Other signed attributes MAY also be included.
	signatureAlgorithm		signatureAlgorithm
	identifies the digital signature algorithm, and any associated		identifies the digital signature algorithm, and any associated
	parameters, used by the RFC Production Center or the IETF		parameters, used by the RFC Production Center or the IETF
	Secretariat to generate the digital signature.		Secretariat to generate the digital signature.
	signature		signature
	is the digital signature value generated by the RFC Production		is the digital signature value generated by the RFC Production
	Center or the IETF Secretariat.		Center or the IETF Secretariat.
	unsignedAttrs		unsignedAttrs
	is an optional set of attributes that are not signed. Unsigned		is an optional set of attributes that are not signed. Unsigned
	attributes are usually omitted; however, the unsigned		attributes are usually omitted; however, the unsigned
	attributes MAY hold a trusted timestamp generated in accordance		attributes MAY hold a trusted timestamp generated in accordance
	with [TSP]. Section 2.2.4 of [TSP] provides more information		with [TSP]. Section 2.2.4 of [TSP] provides more information
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 40 ¶
	contains a content type identifier, and the same value appears in the		contains a content type identifier, and the same value appears in the
	content-type attribute as described in Section 4.2.3.1.		content-type attribute as described in Section 4.2.3.1.
	The following table lists the file formats and the associated content		The following table lists the file formats and the associated content
	type.		type.
	File Format Content Type		File Format Content Type
	----------- ------------		----------- ------------
	Plain text id-ct-asciiTextWithCRLF		Plain text id-ct-asciiTextWithCRLF
	Extensible Markup Language (XML) id-ct-xml		Extensible Markup Language (XML) id-ct-xml
			Portable Document Format (PDF) id-ct-pdf
	PostScript id-ct-postscript		PostScript id-ct-postscript
	HyperText Markup Language (HTML) id-ct-htmlWithCRLF		HyperText Markup Language (HTML) id-ct-htmlWithCRLF
	The object identifiers associated with the content types listed in		The object identifiers associated with the content types listed in
	the above table are:		the above 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-xml OBJECT IDENTIFIER ::= { id-ct 28 }		id-ct-xml OBJECT IDENTIFIER ::= { id-ct 28 }
			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 <TBD1> }		id-ct-htmlWithCRLF OBJECT IDENTIFIER ::= { id-ct <TBD1> }
	6. IANA Considerations		6. IANA Considerations
	Please assign and object identifier for id-ct-htmlWithCRLF in the SMI		Please assign and object identifier for id-ct-htmlWithCRLF in the SMI
	Security for S/MIME CMS Content Type registry.		Security for S/MIME CMS Content Type registry.
	7. Security Considerations		7. Security Considerations
	skipping to change at page 13, line 21 ¶		skipping to change at page 14, line 7 ¶
	operated by the RFC Production Center and IETF Secretariat, they		operated by the RFC Production Center and IETF Secretariat, they
	ought to be owned by the IETF Trust. Accordingly, the Trustees of		ought to be owned by the IETF Trust. Accordingly, the Trustees of
	the IETF Trust should designate an appropriate certification		the IETF Trust should designate an appropriate certification
	authority to issue a certificate to the RFC Editor and the IETF		authority to issue a certificate to the RFC Editor and the IETF
	Secretariat, and they should approve any procedures used by the RFC		Secretariat, and they should approve any procedures used by the RFC
	Production Center and the IETF Secretariat for signing documents		Production Center and the IETF Secretariat for signing documents
	consistent with this specification.		consistent with this specification.
	9. Design Rationale		9. Design Rationale
	A detached signature is used for all file formats, except PDF.		A detached signature is used for all file formats. In addition, RFCs
			in PDF format are also signed with an embedded signature.
	PDF has a widely deployed way of handling digital signatures.		PDF has a widely deployed way of handling digital signatures, and the
	Therefore, tools for verifying PDF digital signatures are freely		tools for verifying the embedded PDF digital signatures are freely
	available.		available.
	Other file formats do not have widely deployed file-format-specific		Other file formats do not have widely deployed file-format-specific
	ways of handling digital signatures. Use of the detached signature		ways of handling digital signatures. Use of the detached signature
	provides a single way to sign RFCs and Internet-Drafts that is easy		provides a single way to sign RFCs and Internet-Drafts that is easy
	to implement using freely available tools.		to implement using freely available tools. In addition, if an
			Internet-Draft author includes a signature using a file-format-
			specific approach, the IETF Secretariat signature does not harm it in
			any way.
	File names provide a straightforward linkage between the document and		File names provide a straightforward linkage between the document and
	the detached signature file. A CMS signed attribute could have been		the detached signature file. A CMS signed attribute could have been
	specified to include another form of linkage, and this could be added		specified to include another form of linkage, and this could be added
	in the future. At this point in time, it is important to support		in the future. At this point in time, it is important to support
	signature validation of expired Internet-Drafts regardless of the way		signature validation of expired Internet-Drafts regardless of the way
	that they are obtained. Therefore, the appropriate value for such a		that they are obtained. Therefore, the appropriate value for such a
	signed attribute is unclear. This specification allows an Internet-		signed attribute is unclear. This specification allows an Internet-
	Draft and companion signature file to be stored anywhere without		Draft and companion signature file to be stored anywhere without
	hindering signature validation.		hindering signature validation.
	skipping to change at page 14, line 29 ¶		skipping to change at page 15, line 19 ¶
	11. Informative References		11. Informative References
	[BinTime] Housley, R., "BinaryTime: An Alternate Format for		[BinTime] Housley, R., "BinaryTime: An Alternate Format for
	Representing Date and Time in ASN.1", RFC 4049,		Representing Date and Time in ASN.1", RFC 4049,
	April 2005.		April 2005.
	[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.
			[IDSIG] Housley, R., "Digital Signatures on Internet-Draft
			Documents", RFC 5485, March 2009.
	[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail		[MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
	Extensions (S/MIME) Version 3.1 Message Specification",		Extensions (S/MIME) Version 3.1 Message Specification",
	RFC 3851, July 2004.		RFC 3851, July 2004.
	[OpenSSL] http://www.openssl.org/		[OpenSSL] http://www.openssl.org/
	[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.
	[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness		[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
	Recommendations for Security", BCP 106, RFC 4086,		Recommendations for Security", BCP 106, RFC 4086,
	June 2005.		June 2005.
	[RFC5485] Housley, R., "Digital Signatures on Internet-Draft
	Documents", RFC 5485, March 2009.
	[RFCED] Kolkman, O., and J. Halpern, "RFC Editor Model		[RFCED] Kolkman, O., and J. Halpern, "RFC Editor Model
	(Version 2)", RFC 6635, June 2012.		(Version 2)", RFC 6635, June 2012.
	[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.
	[TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,		[TSP] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
	skipping to change at page 15, line 23 ¶		skipping to change at page 16, line 13 ¶
	Network Interchange", RFC 5198, March 2008.		Network Interchange", RFC 5198, March 2008.
	[X.501] ITU-T Recommendation X.501: Information Technology -		[X.501] ITU-T Recommendation X.501: Information Technology -
	Open Systems Interconnection - The Directory: Models,		Open Systems Interconnection - The Directory: Models,
	1993.		1993.
	12. Acknowledgements		12. 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 in
	Glen Barney played a key role in implementing Internet-Draft		the creation of [IDSIG]. Glen Barney played a vital role in
	signatures as specified in [RFC5485].		implementing Internet-Draft signatures as specified in [IDSIG].
	The IETF Secretariat has been generating digital signatures for many		The IETF Secretariat has been generating digital signatures for many
	years. Recently, the RFC Series Editor, Heather Flanagan, decided		years. Recently, the RFC Series Editor, Heather Flanagan, decided
	that the RFC Production Center should sign RFCs before they are		that the RFC Production Center should sign RFCs before they are
	posted by the RFC Publisher. In addition, as part of the format		posted by the RFC Publisher. In addition, as part of the format
	changes that are underway [RFCED], the decision was made to take		changes that are underway [RFCED], the decision was made to take
	advantage of the native digital signature capabilities available in		advantage of the native digital signature capabilities available in
	PDF.		PDF.
			Many thanks for Joe Hildebrand and Robert Sparks for their insightful
			suggestions on this document.
	Appendix: A		Appendix: A
	OpenSSL 0.9.9 (and later versions) [OpenSSL] includes an		OpenSSL 0.9.9 (and later versions) [OpenSSL] includes an
	implementation of CMS. The following command line can be used to		implementation of CMS. The following command line can be used to
	verify a detached signature on a RFC or Internet-Draft:		verify a detached signature on a RFC or Internet-Draft:
	openssl cms -verify -CAfile <cert-file> -content <signed-doc> /		openssl cms -verify -CAfile <cert-file> -content <signed-doc> /
	-inform DER -in <p7s-file> -out /dev/null		-inform DER -in <p7s-file> -out /dev/null
	The arguments need to be provided as follows:		The arguments need to be provided as follows:
End of changes. 21 change blocks.
	35 lines changed or deleted		58 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/