< draft-housley-internet-draft-sig-file-07.txt		draft-housley-internet-draft-sig-file-08.txt >
	INTERNET DRAFT R. Housley		INTERNET DRAFT R. Housley
	Intended Status: Informational Vigil Security		Intended Status: Informational Vigil Security
	Expires: 21 June 2009 21 December 2008		Expires: 29 July 2009 29 January 2009
	Digital Signatures on Internet-Draft Documents		Digital Signatures on Internet-Draft Documents
	<draft-housley-internet-draft-sig-file-07.txt>		<draft-housley-internet-draft-sig-file-08.txt>
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 3, line 30 ¶		skipping to change at page 3, line 30 ¶
	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
	Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s		Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s
	The IETF Secretariat will post the signature file in the repository		The IETF Secretariat will post the signature file in the repository
	shortly after the Internet-Draft is posted.		shortly after the Internet-Draft is posted.
	2.1. Need for Canonicalization of Text Files		2.1. Need for Canonicalization
	In general, the content of the Internet-Draft is treated like a		In general, the content of the Internet-Draft is treated like a
	single octet string for the generation of the digital signature.		single octet string for the generation of the digital signature.
	Unfortunately, the plain text file requires canonicalization to avoid		Unfortunately, the plain text file requires canonicalization to avoid
	signature validation problems. The primary concern is the manner in		signature validation problems. The primary concern is the manner in
	which different operating systems indicate the end of a line of text.		which different operating systems indicate the end of a line of text.
	Some systems use a single new-line character, other systems use the		Some systems use a single new-line character, other systems use the
	combination of the carriage-return character followed by a line-feed		combination of the carriage-return character followed by a line-feed
	character, and other systems use fixed-length records padded with		character, and other systems use fixed-length records padded with
	space characters. For the digital signature to validate properly, a		space characters. For the digital signature to validate properly, a
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	Trailing blank lines MUST NOT appear at the end of the file. That		Trailing blank lines MUST NOT appear at the end of the file. That
	is, the file must not end with multiple consecutive <CRLF> sequences.		is, the file must not end with multiple consecutive <CRLF> sequences.
	Any end-of-file marker used by an operating system is not considered		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		to be part of the file content. When present, such end-of-file
	markers MUST NOT be processed by the digital signature algorithm.		markers MUST NOT be processed by the digital signature algorithm.
	Note: This text file canonicalization procedure is consistent with		Note: This text file canonicalization procedure is consistent with
	the ASCII NVT Definition offered in Appendix B of RFC 5198 [UFNI].		the ASCII NVT Definition offered in Appendix B of RFC 5198 [UFNI].
	2.3. Canonicalization of Other File Formats		2.3. XML File Canonicalization
	No canonicalization is needed for file formats other than plain text		In accordance with guidance the World Wide Web Consortium (W3C) in
	files. Other file formats are treated as a simple sequence of octets		Section 2.11 of [R20060816], a <LF> character MUST be used to denote
	by the digital signature algorithm.		the end of a line of text within a XML file. Any two-character
			<CRLF> sequence and any <CR> that is not followed by <LF> are to be
			translated to a single <LF> character.
			2.4. Canonicalization of Other File Formats
			No canonicalization is needed for file formats currently used for
			Internet-Drafts other than plain text files and XML files. Other
			file formats are treated as a simple sequence of octets by the
			digital signature algorithm.
	3. CMS Profile		3. CMS Profile
	CMS is used to construct the detached signature of the Internet-		CMS is used to construct the detached signature of the Internet-
	Draft. The CMS ContentInfo content type MUST always be present, and		Draft. The CMS ContentInfo content type MUST always be present, and
	it MUST encapsulate the CMS SignedData content type. Since a		it MUST encapsulate the CMS SignedData content type. Since a
	detached signature is being created, the CMS SignedData content type		detached signature is being created, the CMS SignedData content type
	MUST NOT encapsulate the Internet-Draft. The CMS detached signature		MUST NOT encapsulate the Internet-Draft. The CMS detached signature
	is summarized by:		is summarized by:
	skipping to change at page 9, line 23 ¶		skipping to change at page 9, line 23 ¶
	3.2.3.2. Message-Digest Attribute		3.2.3.2. Message-Digest Attribute
	The IETF Secretariat MUST include a message-digest attribute, having		The IETF Secretariat MUST include a message-digest attribute, having
	as its value the output of a one-way hash function computed on the		as its value the output of a one-way hash function computed on the
	Internet-Draft that is being signed. Section 11.2 of [CMS] defines		Internet-Draft that is being signed. Section 11.2 of [CMS] defines
	the message-digest attribute.		the message-digest attribute.
	3.2.3.3. Signing-Time Attribute		3.2.3.3. Signing-Time Attribute
	The IETF Secretariat MUST include signing-time attribute, specifying		The IETF Secretariat MUST include a signing-time attribute,
	the time, based on the local system clock, at which the digital		specifying the time, based on the local system clock, at which the
	signature was applied to the Internet-Draft. Since the IETF		digital signature was applied to the Internet-Draft. Since the IETF
	Secretariat may choose to perform signatures in batches, the signing-		Secretariat may choose to perform signatures in batches, the signing-
	time may be several hours or days after the time that the Internet-		time may be several hours or days after the time that the Internet-
	Draft was actually posted. Section 11.3 of [CMS] defines the		Draft was actually posted. Section 11.3 of [CMS] defines the
	content-type attribute.		content-type attribute.
	3.2.3.4. Binary-Signing-Time Attribute		3.2.3.4. Binary-Signing-Time Attribute
	The IETF Secretariat MAY include a binary-signing-time attribute,		The IETF Secretariat MAY include a binary-signing-time attribute,
	specifying the time at which the digital signature was applied to the		specifying the time at which the digital signature was applied to the
	Internet-Draft. If present, the time that is represented MUST match		Internet-Draft. If present, the time that is represented MUST match
	skipping to change at page 11, line 29 ¶		skipping to change at page 11, line 29 ¶
	the signing time attributes supplied by the IETF Secretariat provides		the signing time attributes supplied by the IETF Secretariat provides
	confidence about the date that the Internet-Draft was posted to the		confidence about the date that the Internet-Draft was posted to the
	repository. However, the IETF Secretariat may choose to perform		repository. However, the IETF Secretariat may choose to perform
	signatures in batches, and the signing-time may be several hours or		signatures in batches, and the signing-time may be several hours or
	days after the time that the Internet-Draft was actually posted.		days after the time that the Internet-Draft was actually posted.
	The IETF Secretariat may choose to sign Internet-Drafts in batches.		The IETF Secretariat may choose to sign Internet-Drafts in batches.
	This allows a single HSM to be used if multiple servers are located		This allows a single HSM to be used if multiple servers are located
	in one geographic location, and it allows the HSM to be off-line		in one geographic location, and it allows the HSM to be off-line
	except when signatures are being generated. Further, this allows the		except when signatures are being generated. Further, this allows the
	IETF Secretariat to could include manual steps, such as entering a		IETF Secretariat to include manual steps, such as entering a HSM
	HSM passphrase or inserting a smartcard, as part of the signing		passphrase or inserting a smartcard, as part of the signing procedure
	procedure to improve operations security.		to improve operations security.
	6. Deployment and Operational Considerations		6. Deployment and Operational Considerations
	The private key used to generate the IETF Secretariat signature ought		The private key used to generate the IETF Secretariat signature ought
	to be stored in a HSM to provide protection from unauthorized		to be stored in a HSM to provide protection from unauthorized
	disclosure. While the HSM will be operated by the IETF Secretariat,		disclosure. While the HSM will be operated by the IETF Secretariat,
	it ought to be owned by the IETF Trust. Accordingly, the Trustees of		it ought to be owned by the IETF Trust. Accordingly, the Trustees of
	the IETF Trust will designate an appropriate certification authority		the IETF Trust will designate an appropriate certification authority
	to issue a certificate to the IETF Secretariat, and they will approve		to issue a certificate to the IETF Secretariat, and they will approve
	any procedures used by the IETF Secretariat for signing documents		any procedures used by the IETF Secretariat for signing documents
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 11 ¶
	[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., 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,
			and F. Yergeau, "Extensible Markup Language (XML) 1.0
			(Fourth Edition)", W3C Recommendation, 16 August 2006.
			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.
	[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,
	"Internet X.509 Public Key Infrastructure Time-Stamp		"Internet X.509 Public Key Infrastructure Time-Stamp
	Protocol (TSP)", RFC 3161, August 2001.		Protocol (TSP)", RFC 3161, August 2001.
	skipping to change at page 13, line 33 ¶		skipping to change at page 13, line 38 ¶
	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.
	9. Acknowledgements		9. 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. Many helpful suggestions		with Scott Bradner at IETF 69 in Chicago. Many helpful suggestions
	came from Jim Schaad and Pasi Eronen.		came from Jim Schaad, Pasi Eronen, and Chris Newman.
	10. IANA Considerations		10. IANA Considerations
	None.		None.
	{{{ RFC Editor: Please remove this section prior to publication. }}}		{{{ RFC Editor: Please remove this section prior to publication. }}}
	Appendix: A		Appendix: A
	OpenSSL 0.9.9 [OpenSSL] includes an implementation of CMS. The		OpenSSL 0.9.9 [OpenSSL] includes an implementation of CMS. The
End of changes. 9 change blocks.
	14 lines changed or deleted		28 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/