rfc7468v1.txt		rfc7468.txt
	Internet Engineering Task Force (IETF) S. Josefsson		Internet Engineering Task Force (IETF) S. Josefsson
	Request for Comments: 7468 SJD AB		Request for Comments: 7468 SJD AB
	Category: Standards Track S. Leonard		Category: Standards Track S. Leonard
	ISSN: 2070-1721 Penango, Inc.		ISSN: 2070-1721 Penango, Inc.
	February 2015		March 2015
	Textual Encodings of PKIX, PKCS, and CMS Structures		Textual Encodings of PKIX, PKCS, and CMS Structures
	Abstract		Abstract
	This document describes and discusses the textual encodings of the		This document describes and discusses the textual encodings of the
	Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography		Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography
	Standards (PKCS), and Cryptographic Message Syntax (CMS). The		Standards (PKCS), and Cryptographic Message Syntax (CMS). The
	textual encodings are well-known, are implemented by several		textual encodings are well-known, are implemented by several
	applications and libraries, and are widely deployed. This document		applications and libraries, and are widely deployed. This document
	skipping to change at page 2, line 30		skipping to change at page 2, line 30
	Private Key Info . . . . . . . . . . . . . . . . . . . . . . 12		Private Key Info . . . . . . . . . . . . . . . . . . . . . . 12
	11. Textual Encoding of PKCS #8 Encrypted Private Key Info . . . 12		11. Textual Encoding of PKCS #8 Encrypted Private Key Info . . . 12
	12. Textual Encoding of Attribute Certificates . . . . . . . . . 13		12. Textual Encoding of Attribute Certificates . . . . . . . . . 13
	13. Textual Encoding of Subject Public Key Info . . . . . . . . . 13		13. Textual Encoding of Subject Public Key Info . . . . . . . . . 13
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 14		14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	15.1. Normative References . . . . . . . . . . . . . . . . . . 14		15.1. Normative References . . . . . . . . . . . . . . . . . . 14
	15.2. Informative References . . . . . . . . . . . . . . . . . 15		15.2. Informative References . . . . . . . . . . . . . . . . . 15
	Appendix A. Non-conforming Examples . . . . . . . . . . . . . . 17		Appendix A. Non-conforming Examples . . . . . . . . . . . . . . 17
	Appendix B. DER Expectations . . . . . . . . . . . . . . . . . . 18		Appendix B. DER Expectations . . . . . . . . . . . . . . . . . . 18
	Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 19		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Several security-related standards used on the Internet define ASN.1		Several security-related standards used on the Internet define ASN.1
	data formats that are normally encoded using the Basic Encoding Rules		data formats that are normally encoded using the Basic Encoding Rules
	(BER) or Distinguished Encoding Rules (DER) [X.690], which are		(BER) or Distinguished Encoding Rules (DER) [X.690], which are
	binary, octet-oriented encodings. This document is about the textual		binary, octet-oriented encodings. This document is about the textual
	encodings of the following formats:		encodings of the following formats:
	1. Certificates, Certificate Revocation Lists (CRLs), and Subject		1. Certificates, Certificate Revocation Lists (CRLs), and Subject
	skipping to change at page 4, line 22		skipping to change at page 4, line 22
	content is a PKIX certificate (see further below). Generators MUST		content is a PKIX certificate (see further below). Generators MUST
	put the same label on the "-----END " line (post-encapsulation		put the same label on the "-----END " line (post-encapsulation
	boundary) as the corresponding "-----BEGIN " line. Labels are		boundary) as the corresponding "-----BEGIN " line. Labels are
	formally case-sensitive, uppercase, and comprised of zero or more		formally case-sensitive, uppercase, and comprised of zero or more
	characters; they do not contain consecutive spaces or hyphen-minuses,		characters; they do not contain consecutive spaces or hyphen-minuses,
	nor do they contain spaces or hyphen-minuses at either end. Parsers		nor do they contain spaces or hyphen-minuses at either end. Parsers
	MAY disregard the label in the post-encapsulation boundary instead of		MAY disregard the label in the post-encapsulation boundary instead of
	signaling an error if there is a label mismatch: some extant		signaling an error if there is a label mismatch: some extant
	implementations require the labels to match; others do not.		implementations require the labels to match; others do not.
	There is exactly one space character (SP) separating the "BEGIN" or		There is exactly one space character (?SP?) separating the "BEGIN" or
	"END" from the label. There are exactly five hyphen-minus (also		"END" from the label. There are exactly five hyphen-minus (also
	known as dash) characters ("-") on both ends of the encapsulation		known as dash) characters ("-") on both ends of the encapsulation
	boundaries, no more, no less.		boundaries, no more, no less.
	The label type implies that the encoded data follows the specified		The label type implies that the encoded data follows the specified
	syntax. Parsers MUST handle non-conforming data gracefully.		syntax. Parsers MUST handle non-conforming data gracefully.
	However, not all parsers or generators prior to this document behave		However, not all parsers or generators prior to this document behave
	consistently. A conforming parser MAY interpret the contents as		consistently. A conforming parser MAY interpret the contents as
	another label type but ought to be aware of the security implications		another label type but ought to be aware of the security implications
	discussed in the Security Considerations section. The labels		discussed in the Security Considerations section. The labels
	described in this document identify container formats that are not		described in this document identify container formats that are not
	specific to any particular cryptographic algorithm, a property		specific to any particular cryptographic algorithm, a property
	consistent with algorithm agility. These formats use the ASN.1		consistent with algorithm agility. These formats use the ASN.1
	"AlgorithmIdentifier" structure as described in Section 4.1.1.2 of		?AlgorithmIdentifier? structure as described in Section 4.1.1.2 of
	[RFC5280].		[RFC5280].
	Unlike legacy PEM encoding [RFC1421], OpenPGP ASCII armor, and the		Unlike legacy PEM encoding [RFC1421], OpenPGP ASCII armor, and the
	OpenSSH key file format, textual encoding does *not* define or permit		OpenSSH key file format, textual encoding does *not* define or permit
	headers to be encoded alongside the data. Empty space can appear		headers to be encoded alongside the data. Empty space can appear
	between the pre-encapsulation boundary and the base64, but generators		between the pre-encapsulation boundary and the base64, but generators
	SHOULD NOT emit such any such spacing. (The provision for this empty		SHOULD NOT emit such any such spacing. (The provision for this empty
	area is a throwback to PEM, which defined an "encapsulated header		area is a throwback to PEM, which defined an "encapsulated header
	portion".)		portion".)
	Implementers need to be aware that extant parsers diverge		Implementers need to be aware that extant parsers diverge
	considerably on the handling of whitespace. In this document,		considerably on the handling of whitespace. In this document,
	"whitespace" means any character or series of characters that		"whitespace" means any character or series of characters that
	represent horizontal or vertical space in typography. In US-ASCII,		represent horizontal or vertical space in typography. In US-ASCII,
	whitespace means HT (0x09), VT (0x0B), FF (0x0C), SP (0x20), CR		whitespace means ?HT? (0x09), ?VT? (0x0B), ?FF? (0x0C), ?SP? (0x20),
	(0x0D), and LF (0x0A); "blank" means HT and SP; lines are divided		?CR? (0x0D), and ?LF? (0x0A); "blank" means ?HT? and ?SP?; lines are
	with CRLF, CR, or LF. The common ABNF production WSP is congruent		divided with ?CRLF?, ?CR?, or ?LF?. The common ABNF production ?WSP?
	with "blank"; a new production W is used for "whitespace". The ABNF		is congruent with "blank"; a new production ?W? is used for
	in Section 3 is specific to US-ASCII. As these textual encodings can		"whitespace". The ABNF in Section 3 is specific to US-ASCII. As
	be used on many different systems as well as on long-term archival		these textual encodings can be used on many different systems as well
	storage media such as paper or engravings, an implementer ought to		as on long-term archival storage media such as paper or engravings,
	use the spirit rather than the letter of the rules when generating or		an implementer ought to use the spirit rather than the letter of the
	parsing these formats in environments that are not strictly limited		rules when generating or parsing these formats in environments that
	to US-ASCII.		are not strictly limited to US-ASCII.
	Most extant parsers ignore blanks at the ends of lines; blanks at the		Most extant parsers ignore blanks at the ends of lines; blanks at the
	beginnings of lines or in the middle of the base64-encoded data are		beginnings of lines or in the middle of the base64-encoded data are
	far less compatible. These observations are codified in Figure 1.		far less compatible. These observations are codified in Figure 1.
	The most lax parser implementations are not line-oriented at all and		The most lax parser implementations are not line-oriented at all and
	will accept any mixture of whitespace outside of the encapsulation		will accept any mixture of whitespace outside of the encapsulation
	boundaries (see Figure 2). Such lax parsing may run the risk of		boundaries (see Figure 2). Such lax parsing may run the risk of
	accepting text that was not intended to be accepted in the first		accepting text that was not intended to be accepted in the first
	place (e.g., because the text was a snippet or sample).		place (e.g., because the text was a snippet or sample).
	skipping to change at page 6, line 29		skipping to change at page 6, line 29
	base64finl = *base64char (base64pad *WSP eol base64pad /		base64finl = *base64char (base64pad *WSP eol base64pad /
	*2base64pad) *WSP eol		*2base64pad) *WSP eol
	; ...AB= <EOL> = <EOL> is not good, but is valid		; ...AB= <EOL> = <EOL> is not good, but is valid
	base64text = *base64line base64finl		base64text = *base64line base64finl
	; we could also use <encbinbody> from RFC 1421, which requires		; we could also use <encbinbody> from RFC 1421, which requires
	; 16 groups of 4 chars, which means exactly 64 chars per		; 16 groups of 4 chars, which means exactly 64 chars per
	; line, except the final line, but this is more accurate		; line, except the final line, but this is more accurate
	labelchar = %x21-2C / %x2E-%7E ; any printable character,		labelchar = %x21-2C / %x2E-7E ; any printable character,
	; except hyphen-minus		; except hyphen-minus
	label = [ labelchar *( ["-" / SP] labelchar ) ] ; empty ok		label = [ labelchar *( ["-" / SP] labelchar ) ] ; empty ok
	eol = CRLF / CR / LF		eol = CRLF / CR / LF
	eolWSP = WSP / CR / LF ; compare with LWSP		eolWSP = WSP / CR / LF ; compare with LWSP
	Figure 1: ABNF (Standard)		Figure 1: ABNF (Standard)
	skipping to change at page 8, line 31		skipping to change at page 8, line 31
	been carried forward through PKCS #12 [RFC7292].		been carried forward through PKCS #12 [RFC7292].
	Figure 5: ASN.1 Module Object Identifier Value Assignments		Figure 5: ASN.1 Module Object Identifier Value Assignments
	5. Textual Encoding of Certificates		5. Textual Encoding of Certificates
	5.1. Encoding		5.1. Encoding
	Public-key certificates are encoded using the "CERTIFICATE" label.		Public-key certificates are encoded using the "CERTIFICATE" label.
	The encoded data MUST be a BER (DER strongly preferred; see		The encoded data MUST be a BER (DER strongly preferred; see
	Appendix B) encoded ASN.1 "Certificate" structure as described in		Appendix B) encoded ASN.1 ?Certificate? structure as described in
	Section 4 of [RFC5280].		Section 4 of [RFC5280].
	-----BEGIN CERTIFICATE-----		-----BEGIN CERTIFICATE-----
	MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G		MIICLDCCAdKgAwIBAgIBADAKBggqhkjOPQQDAjB9MQswCQYDVQQGEwJCRTEPMA0G
	A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y		A1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2VydGlmaWNhdGUgYXV0aG9y
	aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0		aXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdudVRMUyBjZXJ0aWZpY2F0
	ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw		ZSBhdXRob3JpdHkwHhcNMTEwNTIzMjAzODIxWhcNMTIxMjIyMDc0MTUxWjB9MQsw
	CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy		CQYDVQQGEwJCRTEPMA0GA1UEChMGR251VExTMSUwIwYDVQQLExxHbnVUTFMgY2Vy
	dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu		dGlmaWNhdGUgYXV0aG9yaXR5MQ8wDQYDVQQIEwZMZXV2ZW4xJTAjBgNVBAMTHEdu
	dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB		dVRMUyBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkwWTATBgcqhkjOPQIBBggqhkjOPQMB
	skipping to change at page 10, line 9		skipping to change at page 10, line 9
	This section does not disturb the official application/pkix-cert		This section does not disturb the official application/pkix-cert
	registration [RFC2585] in any way (which states that "each '.cer'		registration [RFC2585] in any way (which states that "each '.cer'
	file contains exactly one certificate, encoded in DER format"), but		file contains exactly one certificate, encoded in DER format"), but
	merely articulates a widespread, de facto alternative.		merely articulates a widespread, de facto alternative.
	6. Textual Encoding of Certificate Revocation Lists		6. Textual Encoding of Certificate Revocation Lists
	Certificate Revocation Lists (CRLs) are encoded using the "X509 CRL"		Certificate Revocation Lists (CRLs) are encoded using the "X509 CRL"
	label. The encoded data MUST be a BER (DER strongly preferred; see		label. The encoded data MUST be a BER (DER strongly preferred; see
	Appendix B) encoded ASN.1 "CertificateList" structure as described in		Appendix B) encoded ASN.1 ?CertificateList? structure as described in
	Section 5 of [RFC5280].		Section 5 of [RFC5280].
	-----BEGIN X509 CRL-----		-----BEGIN X509 CRL-----
	MIIB9DCCAV8CAQEwCwYJKoZIhvcNAQEFMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s		MIIB9DCCAV8CAQEwCwYJKoZIhvcNAQEFMIIBCDEXMBUGA1UEChMOVmVyaVNpZ24s
	IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT		IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT
	PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu		PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYu
	LExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEm		LExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEm
	MCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxGDAWBgNVBAMU		MCQGA1UECxMdRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUxGDAWBgNVBAMU
	D1NpbW9uIEpvc2Vmc3NvbjEiMCAGCSqGSIb3DQEJARYTc2ltb25Aam9zZWZzc29u		D1NpbW9uIEpvc2Vmc3NvbjEiMCAGCSqGSIb3DQEJARYTc2ltb25Aam9zZWZzc29u
	Lm9yZxcNMDYxMjI3MDgwMjM0WhcNMDcwMjA3MDgwMjM1WjAjMCECEC4QNwPfRoWd		Lm9yZxcNMDYxMjI3MDgwMjM0WhcNMDcwMjA3MDgwMjM1WjAjMCECEC4QNwPfRoWd
	skipping to change at page 10, line 38		skipping to change at page 10, line 38
	Historically, the label "CRL" has rarely been used. Today, it is not		Historically, the label "CRL" has rarely been used. Today, it is not
	common and many popular tools do not understand the label.		common and many popular tools do not understand the label.
	Therefore, this document standardizes "X509 CRL" in order to promote		Therefore, this document standardizes "X509 CRL" in order to promote
	interoperability and backwards-compatibility. Generators conforming		interoperability and backwards-compatibility. Generators conforming
	to this document MUST generate "X509 CRL" labels and MUST NOT		to this document MUST generate "X509 CRL" labels and MUST NOT
	generate "CRL" labels. Parsers SHOULD NOT treat "CRL" as equivalent		generate "CRL" labels. Parsers SHOULD NOT treat "CRL" as equivalent
	to "X509 CRL".		to "X509 CRL".
	7. Textual Encoding of PKCS #10 Certification Request Syntax		7. Textual Encoding of PKCS #10 Certification Request Syntax
	PKCS #10 Certification Requests are encoded using the "CERTIFICATE		PKCS #10 Certification Requests are encoded using the
	REQUEST" label. The encoded data MUST be a BER (DER strongly		"CERTIFICATE REQUEST" label. The encoded data MUST be a BER (DER
	preferred; see Appendix B) encoded ASN.1 "CertificationRequest"		strongly preferred; see Appendix B) encoded ASN.1
	structure as described in [RFC2986].		?CertificationRequest? structure as described in [RFC2986].
	-----BEGIN CERTIFICATE REQUEST-----		-----BEGIN CERTIFICATE REQUEST-----
	MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm		MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
	c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG		c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
	ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM		ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
	EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY		EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY
	BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/		BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/
	BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8		BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8
	AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY		AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY
	dEQc8B8jAcnuOrfU		dEQc8B8jAcnuOrfU
	skipping to change at page 11, line 27		skipping to change at page 11, line 27
	The label "NEW CERTIFICATE REQUEST" is also in wide use. Generators		The label "NEW CERTIFICATE REQUEST" is also in wide use. Generators
	conforming to this document MUST generate "CERTIFICATE REQUEST"		conforming to this document MUST generate "CERTIFICATE REQUEST"
	labels. Parsers MAY treat "NEW CERTIFICATE REQUEST" as equivalent to		labels. Parsers MAY treat "NEW CERTIFICATE REQUEST" as equivalent to
	"CERTIFICATE REQUEST".		"CERTIFICATE REQUEST".
	8. Textual Encoding of PKCS #7 Cryptographic Message Syntax		8. Textual Encoding of PKCS #7 Cryptographic Message Syntax
	PKCS #7 Cryptographic Message Syntax structures are encoded using the		PKCS #7 Cryptographic Message Syntax structures are encoded using the
	"PKCS7" label. The encoded data MUST be a BER-encoded ASN.1		"PKCS7" label. The encoded data MUST be a BER-encoded ASN.1
	"ContentInfo" structure as described in [RFC2315].		?ContentInfo? structure as described in [RFC2315].
	-----BEGIN PKCS7-----		-----BEGIN PKCS7-----
	MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E		MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E
	CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz		CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz
	u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI		u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI
	hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ		hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ
	OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=		OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4=
	-----END PKCS7-----		-----END PKCS7-----
	Figure 10: PKCS #7 Example		Figure 10: PKCS #7 Example
	skipping to change at page 12, line 8		skipping to change at page 12, line 8
	Parsers SHOULD NOT treat "CERTIFICATE CHAIN" as equivalent to		Parsers SHOULD NOT treat "CERTIFICATE CHAIN" as equivalent to
	"PKCS7".		"PKCS7".
	PKCS #7 is an old specification that has long been superseded by CMS		PKCS #7 is an old specification that has long been superseded by CMS
	[RFC5652]. Implementations SHOULD NOT generate PKCS #7 when CMS is		[RFC5652]. Implementations SHOULD NOT generate PKCS #7 when CMS is
	an alternative.		an alternative.
	9. Textual Encoding of Cryptographic Message Syntax		9. Textual Encoding of Cryptographic Message Syntax
	Cryptographic Message Syntax structures are encoded using the "CMS"		Cryptographic Message Syntax structures are encoded using the "CMS"
	label. The encoded data MUST be a BER-encoded ASN.1 "ContentInfo"		label. The encoded data MUST be a BER-encoded ASN.1 ?ContentInfo?
	structure as described in [RFC5652].		structure as described in [RFC5652].
	-----BEGIN CMS-----		-----BEGIN CMS-----
	MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN		MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN
	AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM		AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM
	dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0=		dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0=
	-----END CMS-----		-----END CMS-----
	Figure 11: CMS Example		Figure 11: CMS Example
	skipping to change at page 12, line 31		skipping to change at page 12, line 31
	generate CMS when it is an alternative, promoting interoperability		generate CMS when it is an alternative, promoting interoperability
	and forwards-compatibility.		and forwards-compatibility.
	10. One Asymmetric Key and the Textual Encoding of PKCS #8 Private Key		10. One Asymmetric Key and the Textual Encoding of PKCS #8 Private Key
	Info		Info
	Unencrypted PKCS #8 Private Key Information Syntax structures		Unencrypted PKCS #8 Private Key Information Syntax structures
	(PrivateKeyInfo), renamed to Asymmetric Key Packages		(PrivateKeyInfo), renamed to Asymmetric Key Packages
	(OneAsymmetricKey), are encoded using the "PRIVATE KEY" label. The		(OneAsymmetricKey), are encoded using the "PRIVATE KEY" label. The
	encoded data MUST be a BER (DER preferred; see Appendix B) encoded		encoded data MUST be a BER (DER preferred; see Appendix B) encoded
	ASN.1 "PrivateKeyInfo" structure as described in PKCS #8 [RFC5208],		ASN.1 ?PrivateKeyInfo? structure as described in PKCS #8 [RFC5208],
	or a "OneAsymmetricKey" structure as described in [RFC5958]. The two		or a ?OneAsymmetricKey? structure as described in [RFC5958]. The two
	are semantically identical and can be distinguished by version		are semantically identical and can be distinguished by version
	number.		number.
	-----BEGIN PRIVATE KEY-----		-----BEGIN PRIVATE KEY-----
	MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf		MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgVcB/UNPxalR9zDYAjQIf
	jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK		jojUDiQuGnSJrFEEzZPT/92hRANCAASc7UJtgnF/abqWM60T3XNJEzBv5ez9TdwK
	H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ		H0M6xpM2q+53wmsN/eYLdgtjgBd3DBmHtPilCkiFICXyaA8z9LkJ
	-----END PRIVATE KEY-----		-----END PRIVATE KEY-----
	Figure 12: PKCS #8 PrivateKeyInfo (OneAsymmetricKey) Example		Figure 12: PKCS #8 PrivateKeyInfo (OneAsymmetricKey) Example
	11. Textual Encoding of PKCS #8 Encrypted Private Key Info		11. Textual Encoding of PKCS #8 Encrypted Private Key Info
	Encrypted PKCS #8 Private Key Information Syntax structures		Encrypted PKCS #8 Private Key Information Syntax structures
	(EncryptedPrivateKeyInfo), called the same in [RFC5958], are encoded		(EncryptedPrivateKeyInfo), called the same in [RFC5958], are encoded
	using the "ENCRYPTED PRIVATE KEY" label. The encoded data MUST be a		using the "ENCRYPTED PRIVATE KEY" label. The encoded data MUST be a
	BER (DER preferred; see Appendix B) encoded ASN.1		BER (DER preferred; see Appendix B) encoded ASN.1
	"EncryptedPrivateKeyInfo" structure as described in PKCS #8 [RFC5208]		?EncryptedPrivateKeyInfo? structure as described in PKCS #8 [RFC5208]
	and [RFC5958].		and [RFC5958].
	-----BEGIN ENCRYPTED PRIVATE KEY-----		-----BEGIN ENCRYPTED PRIVATE KEY-----
	MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIb3DQEFDDAOBAghhICA6T/51QICCAAw		MIHNMEAGCSqGSIb3DQEFDTAzMBsGCSqGSIb3DQEFDDAOBAghhICA6T/51QICCAAw
	FAYIKoZIhvcNAwcECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW		FAYIKoZIhvcNAwcECBCxDgvI59i9BIGIY3CAqlMNBgaSI5QiiWVNJ3IpfLnEiEsW
	Z0JIoHyRmKK/+cr9QPLnzxImm0TR9s4JrG3CilzTWvb0jIvbG3hu0zyFPraoMkap		Z0JIoHyRmKK/+cr9QPLnzxImm0TR9s4JrG3CilzTWvb0jIvbG3hu0zyFPraoMkap
	8eRzWsIvC5SVel+CSjoS2mVS87cyjlD+txrmrXOVYDE+eTgMLbrLmsWh3QkCTRtF		8eRzWsIvC5SVel+CSjoS2mVS87cyjlD+txrmrXOVYDE+eTgMLbrLmsWh3QkCTRtF
	QC7k0NNzUHTV9yGDwfqMbw==		QC7k0NNzUHTV9yGDwfqMbw==
	-----END ENCRYPTED PRIVATE KEY-----		-----END ENCRYPTED PRIVATE KEY-----
	Figure 13: PKCS #8 EncryptedPrivateKeyInfo Example		Figure 13: PKCS #8 EncryptedPrivateKeyInfo Example
	12. Textual Encoding of Attribute Certificates		12. Textual Encoding of Attribute Certificates
	Attribute certificates are encoded using the "ATTRIBUTE CERTIFICATE"		Attribute certificates are encoded using the "ATTRIBUTE CERTIFICATE"
	label. The encoded data MUST be a BER (DER strongly preferred; see		label. The encoded data MUST be a BER (DER strongly preferred; see
	Appendix B) encoded ASN.1 "AttributeCertificate" structure as		Appendix B) encoded ASN.1 ?AttributeCertificate? structure as
	described in [RFC5755].		described in [RFC5755].
	-----BEGIN ATTRIBUTE CERTIFICATE-----		-----BEGIN ATTRIBUTE CERTIFICATE-----
	MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVQQI		MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVQQI
	DAhOZXcgWW9yazEUMBIGA1UEBwwLU3RvbnkgQnJvb2sxDzANBgNVBAoMBkNTRTU5		DAhOZXcgWW9yazEUMBIGA1UEBwwLU3RvbnkgQnJvb2sxDzANBgNVBAoMBkNTRTU5
	MjE6MDgGA1UEAwwxU2NvdHQgU3RhbGxlci9lbWFpbEFkZHJlc3M9c3N0YWxsZXJA		MjE6MDgGA1UEAwwxU2NvdHQgU3RhbGxlci9lbWFpbEFkZHJlc3M9c3N0YWxsZXJA
	aWMuc3VueXNiLmVkdQIGARWrgUUSoIGMMIGJpIGGMIGDMQswCQYDVQQGEwJVUzER		aWMuc3VueXNiLmVkdQIGARWrgUUSoIGMMIGJpIGGMIGDMQswCQYDVQQGEwJVUzER
	MA8GA1UECAwITmV3IFlvcmsxFDASBgNVBAcMC1N0b255IEJyb29rMQ8wDQYDVQQK		MA8GA1UECAwITmV3IFlvcmsxFDASBgNVBAcMC1N0b255IEJyb29rMQ8wDQYDVQQK
	DAZDU0U1OTIxOjA4BgNVBAMMMVNjb3R0IFN0YWxsZXIvZW1haWxBZGRyZXNzPXNz		DAZDU0U1OTIxOjA4BgNVBAMMMVNjb3R0IFN0YWxsZXIvZW1haWxBZGRyZXNzPXNz
	dGFsbGVyQGljLnN1bnlzYi5lZHUwDQYJKoZIhvcNAQEFBQACBgEVq4FFSjAiGA8z		dGFsbGVyQGljLnN1bnlzYi5lZHUwDQYJKoZIhvcNAQEFBQACBgEVq4FFSjAiGA8z
	skipping to change at page 13, line 43		skipping to change at page 13, line 43
	5XPus/xS9wBgtlM3fldIKNyNO8RsMp6Ocx+PGlICc7zpZiGmCYLl64lAEGPO/bsw		5XPus/xS9wBgtlM3fldIKNyNO8RsMp6Ocx+PGlICc7zpZiGmCYLl64lAEGPO/bsw
	Smluak1aZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ==		Smluak1aZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ==
	-----END ATTRIBUTE CERTIFICATE-----		-----END ATTRIBUTE CERTIFICATE-----
	Figure 14: Attribute Certificate Example		Figure 14: Attribute Certificate Example
	13. Textual Encoding of Subject Public Key Info		13. Textual Encoding of Subject Public Key Info
	Public keys are encoded using the "PUBLIC KEY" label. The encoded		Public keys are encoded using the "PUBLIC KEY" label. The encoded
	data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1		data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1
	"SubjectPublicKeyInfo" structure as described in Section 4.1.2.7 of		?SubjectPublicKeyInfo? structure as described in Section 4.1.2.7 of
	[RFC5280].		[RFC5280].
	-----BEGIN PUBLIC KEY-----		-----BEGIN PUBLIC KEY-----
	MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEn1LlwLN/KBYQRVH6HfIMTzfEqJOVztLe		MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEn1LlwLN/KBYQRVH6HfIMTzfEqJOVztLe
	kLchp2hi78cCaMY81FBlYs8J9l7krc+M4aBeCGYFjba+hiXttJWPL7ydlE+5UG4U		kLchp2hi78cCaMY81FBlYs8J9l7krc+M4aBeCGYFjba+hiXttJWPL7ydlE+5UG4U
	Nkn3Eos8EiZByi9DVsyfy9eejh+8AXgp		Nkn3Eos8EiZByi9DVsyfy9eejh+8AXgp
	-----END PUBLIC KEY-----		-----END PUBLIC KEY-----
	Figure 15: Subject Public Key Info Example		Figure 15: Subject Public Key Info Example
	skipping to change at page 19, line 31		skipping to change at page 19, line 31
	when generating the encoding. Only certain parts -- namely, signed		when generating the encoding. Only certain parts -- namely, signed
	and authenticated attributes -- need to be DER encoded.		and authenticated attributes -- need to be DER encoded.
	~ Although not always "small", these encoded structures should not be		~ Although not always "small", these encoded structures should not be
	particularly "large" (e.g., more than 16 kilobytes). The parser		particularly "large" (e.g., more than 16 kilobytes). The parser
	ought to be informed of large things up front in any event; this is		ought to be informed of large things up front in any event; this is
	yet another reason to DER encode these things in the first place.		yet another reason to DER encode these things in the first place.
	Figure 20: Guide for DER Encoding		Figure 20: Guide for DER Encoding
	Appendix C. Acknowledgements		Acknowledgements
	Peter Gutmann suggested to document labels for Attribute Certificates		Peter Gutmann suggested to document labels for Attribute Certificates
	and PKCS #7 messages, and to add examples for the non-standard		and PKCS #7 messages, and to add examples for the non-standard
	variants. Dr. Stephen Henson suggested distinguishing when BER		variants. Dr. Stephen Henson suggested distinguishing when BER
	versus DER is appropriate or necessary.		versus DER is appropriate or necessary.
	Authors' Addresses		Authors' Addresses
	Simon Josefsson		Simon Josefsson
	SJD AB		SJD AB
End of changes. 16 change blocks.
	29 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/