< draft-housley-rfc-and-id-signatures-01.txt		draft-housley-rfc-and-id-signatures-02.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: 26 August 2016 24 February 2016		Expires: 11 November 2016 11 May 2016
	Digital Signatures on RFC and Internet-Draft Documents		Digital Signatures on RFC and Internet-Draft Documents
	<draft-housley-rfc-and-id-signatures-01.txt>		<draft-housley-rfc-and-id-signatures-02.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 Internet-Drafts, 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 RFCs, an embedded digital signature is included in		signature. For RFCs, an embedded digital signature is included in
	Portable Document Format (PDF) files types in addition to the		Portable Document Format (PDF) files types in addition to the
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 26 August 2016.		This Internet-Draft will expire on11 November 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
	skipping to change at page 11, line 14 ¶		skipping to change at page 11, line 14 ¶
	4.2.3.4. Binary-Signing-Time Attribute		4.2.3.4. Binary-Signing-Time Attribute
	The RFC Production Center or IETF Secretariat MAY include a binary-		The RFC Production Center or IETF Secretariat MAY include a binary-
	signing-time attribute, specifying the time at which the digital		signing-time attribute, specifying the time at which the digital
	signature was applied to the RFC or Internet-Draft. If present, the		signature was applied to the RFC or Internet-Draft. If present, the
	time that is represented MUST match the time represented in the		time that is represented MUST match the time represented in the
	signing-time attribute. The binary-signing-time attribute is defined		signing-time attribute. The binary-signing-time attribute is defined
	in [BinTime].		in [BinTime].
			4.2.3.5. Signing-Certificate-Version2 Attribute
			The RFC Production Center or IETF Secretariat MAY include a signing-
			certificate-version2 attribute, specifying which certificate is to be
			used to validate the digital signature was applied to the RFC or
			Internet-Draft. If present, the certs field of the attribute MUST
			contain the list of certificates that are to be used in validating
			the RFC or Internet-Draft, and the optional policies field of the
			attribute MUST be absent. The first certificate identified in the
			the certs field of the attribute MUST be the certificate to be used
			to verify the signature on the the RFC or Internet-Draft. If more
			than one certificate identifier is present, the subsequent
			certificate identifiers MUST limit certificates that are acceptable
			during certification path validation. The signing-certificate-
			version2 attribute is defined in [ESSU].
	4.2.4. Unsigned Attributes		4.2.4. Unsigned Attributes
	Unsigned attributes are usually omitted. However, an unsigned		Unsigned attributes are usually omitted. However, an unsigned
	attribute MAY hold a trusted timestamp generated in accordance with		attribute MAY hold a trusted timestamp generated in accordance with
	[TSP]. The idea is to time-stamp the RFC Production Center or the		[TSP]. The idea is to time-stamp the RFC Production Center or the
	IETF Secretariat digital signature to prove that it was created		IETF Secretariat digital signature to prove that it was created
	before a given time. If the certificate of the RFC Editor or the		before a given time. If the certificate of the RFC Editor or the
	IETF Secretariat is revoked the time stamp allows a verifier to know		IETF Secretariat is revoked the time stamp allows a verifier to know
	whether the signature was created before or after the revocation		whether the signature was created before or after the revocation
	date. Appendix A of [TSP] defines the signature time-stamp attribute		date. Appendix A of [TSP] defines the signature time-stamp attribute
	skipping to change at page 15, line 16 ¶		skipping to change at page 15, line 31 ¶
	Information technology - ASN.1 encoding rules: Specification		Information technology - ASN.1 encoding rules: Specification
	of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)		of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
	and Distinguished Encoding Rules (DER).		and Distinguished Encoding Rules (DER).
	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.
			[ESSU] Schaad, J., "Enhanced Security Services (ESS) Update:
			Adding CertID Algorithm Agility", RFC 5035, August 2007.
	[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		[IDSIG] Housley, R., "Digital Signatures on Internet-Draft
	Documents", RFC 5485, March 2009.		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.
	skipping to change at page 16, line 25 ¶		skipping to change at page 16, line 45 ¶
	implementing Internet-Draft signatures as specified in [IDSIG].		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		Many thanks for Joe Hildebrand, Stefan Santesson, and Robert Sparks
	suggestions on this document.		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
End of changes. 6 change blocks.
	5 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/