Diff: rfc9908v1.txt - rfc9908.txt

	rfc9908v1.txt	rfc9908.txt

	skipping to change at line 27 ¶	skipping to change at line 27 ¶
	This document updates RFC 7030, "Enrollment over Secure Transport"	This document updates RFC 7030, "Enrollment over Secure Transport"
	(EST), clarifying how the Certificate Signing Request (CSR)	(EST), clarifying how the Certificate Signing Request (CSR)
	Attributes Response can be used by an EST server to specify both CSR	Attributes Response can be used by an EST server to specify both CSR
	attribute Object Identifiers (OIDs) and CSR attribute values,	attribute Object Identifiers (OIDs) and CSR attribute values,
	particularly X.509 extension values, that the server expects the	particularly X.509 extension values, that the server expects the
	client to include in a subsequent CSR request. RFC 9148 is derived	client to include in a subsequent CSR request. RFC 9148 is derived
	from RFC 7030 and is also updated.	from RFC 7030 and is also updated.

	RFC 7030 is ambiguous in its specification of the CSR Attributes	RFC 7030 is ambiguous in its specification of the CSR Attributes
	Response. This has resulted in implementation challenges and	Response. This has resulted in implementation challenges and

	implementor confusion. As a result, there was no universal	implementor confusion because there was no universal understanding of
	understanding of what was specified. This document clarifies the	what was specified. This document clarifies the encoding rules.
	encoding rules.

	This document also provides a new straightforward approach: using a	This document also provides a new straightforward approach: using a
	template for CSR contents that may be partially filled in by the	template for CSR contents that may be partially filled in by the
	server. This also allows an EST server to specify a subject	server. This also allows an EST server to specify a subject
	Distinguished Name (DN).	Distinguished Name (DN).

	Status of This Memo	Status of This Memo

	This is an Internet Standards Track document.	This is an Internet Standards Track document.


	skipping to change at line 121 ¶	skipping to change at line 120 ¶
	values that it expects the client to include in the subsequent CSR.	values that it expects the client to include in the subsequent CSR.

	"Enrollment over Secure Transport" [RFC7030] has been used in a wide	"Enrollment over Secure Transport" [RFC7030] has been used in a wide
	variety of applications. In particular, [RFC8994] and [RFC8995]	variety of applications. In particular, [RFC8994] and [RFC8995]
	describe a way to use it in order to build out an Autonomic Control	describe a way to use it in order to build out an Autonomic Control
	Plane (ACP) [RFC8368].	Plane (ACP) [RFC8368].

	When bootstrapping the ACP, there is a requirement that each node be	When bootstrapping the ACP, there is a requirement that each node be
	given a very specific subjectAltName. In [RFC8994], the ACP	given a very specific subjectAltName. In [RFC8994], the ACP
	specification, the EST server is specified to make use of the CSR	specification, the EST server is specified to make use of the CSR

	Attributes ("/csrattrs") resource (specified in [RFC7030],	Attributes ("/csrattrs") Request (specified in [RFC7030],
	Section 2.6) to convey the actual subjectAltName to the EST client	Section 2.6) to convey the actual subjectAltName to the EST client
	that needs to go into its CSR and thus ultimately into its End Entity	that needs to go into its CSR and thus ultimately into its End Entity
	(EE) certificate.	(EE) certificate.

	As a result of some implementation challenges, it came to light that	As a result of some implementation challenges, it came to light that

	this particular way of using the CSR attributes was not universally	this particular way of using the CSR Attributes was not universally
	agreed upon, and it was suggested that it went contrary to [RFC7030],	agreed upon, and it was suggested that it went contrary to [RFC7030],
	Section 2.6.	Section 2.6.


	[RFC7030], Section 2.6 says that the CSR attributes "can provide	[RFC7030], Section 2.6 says that the CSR Attributes "can provide
	additional descriptive information that the EST server cannot access	additional descriptive information that the EST server cannot access
	itself". This is extended to describe how the EST server can provide	itself". This is extended to describe how the EST server can provide
	values that it demands be used.	values that it demands be used.

	After significant discussion, it has been determined that Section 4.5	After significant discussion, it has been determined that Section 4.5
	of [RFC7030] is sufficiently difficult to read and ambiguous to	of [RFC7030] is sufficiently difficult to read and ambiguous to
	interpret, so clarification is needed.	interpret, so clarification is needed.

	Also, [RFC7030], Section 4.5.2 is extended to clarify the use of the	Also, [RFC7030], Section 4.5.2 is extended to clarify the use of the
	existing ASN.1 syntax [X.680] [X.690].	existing ASN.1 syntax [X.680] [X.690].

	skipping to change at line 227 ¶	skipping to change at line 226 ¶
	Extension, MUST NOT include more than one element with a particular	Extension, MUST NOT include more than one element with a particular
	extnID.	extnID.

	When not using the template-based approach of Section 3.4, specifying	When not using the template-based approach of Section 3.4, specifying
	the requirement for a public key of a specific type and optionally	the requirement for a public key of a specific type and optionally
	its size and other parameters MUST be done as follows: Include	its size and other parameters MUST be done as follows: Include
	exactly one Attribute with the type field being the OID specifying	exactly one Attribute with the type field being the OID specifying
	the type of the key, such as ecPublicKey or rsaEncryption. The	the type of the key, such as ecPublicKey or rsaEncryption. The
	'values' field MAY be empty to indicate no further requirements on	'values' field MAY be empty to indicate no further requirements on
	the key. Otherwise, it MUST contain suitable parameters for the	the key. Otherwise, it MUST contain suitable parameters for the

	given key type, such as a singleton set containing the OID of an EC	given key type, such as a singleton set containing the OID of an
	curve such as secp384r1 or containing an integer value for the RSA	elliptic curve (EC) (e.g., secp384r1) or containing an integer value
	key size such as 4096. Many examples for this are given in	for the RSA key size (e.g., 4096). Many examples for this are given
	Section 5.	in Section 5.

	3.3. Update to RFC 9148	3.3. Update to RFC 9148

	The updates to EST in this document equally apply when using the	The updates to EST in this document equally apply when using the

	Constrained Application Protocol (CoAP) as a transport as described	Constrained Application Protocol (CoAP) as a transport mechanism as
	in [RFC9148]. This document therefore adds the following paragraph	described in [RFC9148]. This document therefore adds the following
	after the second paragraph of [RFC9148], Section 1:	paragraph after the second paragraph of [RFC9148], Section 1:

	\| EST over CoAP as specified in [RFC9148] applies unchanged to	\| EST over CoAP as specified in [RFC9148] applies unchanged to

	\| [RFC7030] updated by RFC 9908. Hence, all references to [RFC7030]	\| [RFC7030], which is updated by RFC 9908. Hence, all references to
	\| in [RFC9148] are assumed to indicate [RFC7030] updated by RFC	\| [RFC7030] in [RFC9148] are assumed to indicate that [RFC7030] is
	\| 9908.	\| updated by RFC 9908.

	3.4. Use of CSR Templates	3.4. Use of CSR Templates


	As an alternative to the unstructured inclusion of CSR attributes	As an alternative to the unstructured inclusion of CSR Attributes
	specified in Section 4.5.2 of [RFC7030] with its limitations and	specified in Section 4.5.2 of [RFC7030] with its limitations and
	ambiguities, Appendix B of [RFC8295] describes an approach using a	ambiguities, Appendix B of [RFC8295] describes an approach using a
	CSR template. An entire CSR object is returned with various fields	CSR template. An entire CSR object is returned with various fields
	filled out and other fields waiting to be filled in. In that	filled out and other fields waiting to be filled in. In that

	approach, a pKCS7PDU attribute includes a Full PKI Data content type	approach, a pKCS7PDU attribute includes a PKIData content type
	[RFC5272] and that, in turn, includes a CSR [RFC2986] or a	[RFC5272] and that, in turn, includes a CSR [RFC2986] or a
	Certificate Request Message Format (CRMF) formatted request (for	Certificate Request Message Format (CRMF) formatted request (for

	details, see Sections 5 or 9 of [RFC6268], respectively).	details, see 5 or 9 of [RFC6268], respectively).

	One drawback to that approach, particularly for the CSR, is that some	One drawback to that approach, particularly for the CSR, is that some
	unused fields have to be included; specifically, the 'signature'	unused fields have to be included; specifically, the 'signature'
	field on the CSR is faked with an empty bit string.	field on the CSR is faked with an empty bit string.


	A similar method has been defined in "Certificate Management Protocol	A similar method has been defined in "Internet X.509 Public Key
	(CMP) Updates" [RFC9480] and "Lightweight Certificate Management	Infrastructure -- Certificate Management Protocol (CMP)" [RFC9810],
	Protocol (CMP) Profile" ([RFC9483], Section 4.3.3) using a CSR	"Internet X.509 Public Key Infrastructure -- HTTP Transfer for the
	template as defined for CRMF [RFC4211]. Like the approach mentioned	Certificate Management Protocol (CMP)" [RFC9811], and "Lightweight
	before, this method does not properly deal with absent Relative	Certificate Management Protocol (CMP) Profile" ([RFC9483],
	Distinguished Name (RDN) values, as it would encode them as invalid	Section 4.3.3) using a CSR template as defined for CRMF [RFC4211].
	empty strings. Also, encoding an absent 'subjectPublicKey' value as	Like the approach mentioned before, this method does not properly
	an empty BIT STRING and an absent X.509 extension value as an empty	deal with absent Relative Distinguished Name (RDN) values, as it
	OCTET STRING can cause issues with strict ASN.1 parsing and decoding.	would encode them as invalid empty strings. Also, encoding an absent
		'subjectPublicKey' value as an empty BIT STRING and an absent X.509
		extension value as an empty OCTET STRING can cause issues with strict
		ASN.1 parsing and decoding.

	These drawbacks are avoided as follows:	These drawbacks are avoided as follows:

	This specification defines a new Certificate Request Information	This specification defines a new Certificate Request Information
	Template attribute for CsrAttrs (as given in Section 3.2) that is	Template attribute for CsrAttrs (as given in Section 3.2) that is
	essentially a partially filled-in PKCS#10 CSR minus the signature	essentially a partially filled-in PKCS#10 CSR minus the signature
	wrapper:	wrapper:

	CertificationRequestInfoTemplate ::= SEQUENCE {	CertificationRequestInfoTemplate ::= SEQUENCE {
	version INTEGER { v1(0) } (v1, ... ),	version INTEGER { v1(0) } (v1, ... ),

	skipping to change at line 392 ¶	skipping to change at line 394 ¶
	contain a set with exactly one element, and this element MUST be of	contain a set with exactly one element, and this element MUST be of
	type ExtensionTemplate.	type ExtensionTemplate.

	Suppose the server requires that the CSR will contain:	Suppose the server requires that the CSR will contain:

	* the 'subject' field with a common name to be filled in by the EE	* the 'subject' field with a common name to be filled in by the EE
	and two organizational unit names with given values "myDept" and	and two organizational unit names with given values "myDept" and
	"myGroup",	"myGroup",

	* the 'publicKey' field with an Elliptic Curve Cryptography (ECC)	* the 'publicKey' field with an Elliptic Curve Cryptography (ECC)

	key on curve secp256r1,	public key on curve secp256r1,

	* the 'subjectAltName' extension with two entries; one DNS entry	* the 'subjectAltName' extension with two entries; one DNS entry
	with name "www.myServer.com" and IP entry that is empty for the IP	with name "www.myServer.com" and IP entry that is empty for the IP
	address to be filled in,	address to be filled in,

	* the 'keyUsage' extension marked critical with the values	* the 'keyUsage' extension marked critical with the values
	digitalSignature and keyAgreement, and	digitalSignature and keyAgreement, and


	* the 'extKeyUsage' extension with value to be filled in by the EE.	* the 'extKeyUsage' extension with the value to be filled in by the
		EE.

	Then, the CertificationRequestInfo structure constructed by the	Then, the CertificationRequestInfo structure constructed by the
	server will be as follows:	server will be as follows:

	SEQUENCE {	SEQUENCE {
	INTEGER 0	INTEGER 0
	SEQUENCE {	SEQUENCE {
	SET {	SET {
	SEQUENCE {	SEQUENCE {
	OBJECT IDENTIFIER commonName (2 5 4 3)	OBJECT IDENTIFIER commonName (2 5 4 3)

	skipping to change at line 471 ¶	skipping to change at line 474 ¶
	}	}
	}	}
	}	}

	4. Coexistence with Existing Implementations	4. Coexistence with Existing Implementations

	EST servers with legacy clients MAY continue to use the unstructured	EST servers with legacy clients MAY continue to use the unstructured
	list of attribute/value pairs as described in [RFC7030] and MAY also	list of attribute/value pairs as described in [RFC7030] and MAY also
	include the template style described in Section 3.4 for newer	include the template style described in Section 3.4 for newer
	clients. Clients that understand both MUST use the template only,	clients. Clients that understand both MUST use the template only,

	and ignore all other CSRattrs elements. Older clients will ignore	and ignore all other CsrAttrs elements. Older clients will ignore
	the new CertificationRequestInfoTemplate element.	the new CertificationRequestInfoTemplate element.

	5. Examples Using the Original Approach in RFC 7030	5. Examples Using the Original Approach in RFC 7030

	Each example has a high-level (English) explanation of what is	Each example has a high-level (English) explanation of what is
	expected. Some mapping back to the Attribute and Extension	expected. Some mapping back to the Attribute and Extension
	definitions above are included. The base64 DER encoding is then	definitions above are included. The base64 DER encoding is then
	shown. The output of "dumpasn1" [dumpasn1] is then provided to	shown. The output of "dumpasn1" [dumpasn1] is then provided to
	detail what the contents are.	detail what the contents are.


	skipping to change at line 653 ¶	skipping to change at line 656 ¶
	15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)	15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
	: (ANSI X9.62 public key type)	: (ANSI X9.62 public key type)
	<31 07>	<31 07>
	24 7: SET {	24 7: SET {
	<06 05>	<06 05>
	26 5: OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)	26 5: OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
	: (SECG (Certicom) named elliptic curve)	: (SECG (Certicom) named elliptic curve)
	: }	: }
	: }	: }
	<06 09>	<06 09>

	33 9: OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20)	33 9: OBJECT IDENTIFIER friendlyName (for PKCS #12)
		(1 2 840 113549 1 9 20)
	: (PKCS #9 via PKCS #12)	: (PKCS #9 via PKCS #12)
	<06 0A>	<06 0A>
	44 10: OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5'	44 10: OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5'
	<06 03>	<06 03>
	56 3: OBJECT IDENTIFIER serialNumber (2 5 4 5)	56 3: OBJECT IDENTIFIER serialNumber (2 5 4 5)
	: (X.520 DN component)	: (X.520 DN component)
	<06 08>	<06 08>
	61 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)	61 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
	: (ANSI X9.62 ECDSA algorithm with SHA512)	: (ANSI X9.62 ECDSA algorithm with SHA512)
	: }	: }

	skipping to change at line 716 ¶	skipping to change at line 720 ¶

	5.5.1. Base64-Encoded Example	5.5.1. Base64-Encoded Example

	The Base64:	The Base64:

	MC4GCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiBgNV	MC4GCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiBgNV
	BAUGCCqGSM49BAMD	BAUGCCqGSM49BAMD

	5.5.2. ASN.1 DUMP Output	5.5.2. ASN.1 DUMP Output


	Provide a CSR with an ECC key from p384, include your serial number,	Provide a CSR with an ECC public key from p384, include your serial
	and use SHA384 as the hash algorithm within the signature.	number, and use SHA384 as the hash algorithm within the signature.

	<30 2E>	<30 2E>
	0 46: SEQUENCE {	0 46: SEQUENCE {
	<06 09>	<06 09>
	2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)	2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
	: (PKCS #9)	: (PKCS #9)
	<30 12>	<30 12>
	13 18: SEQUENCE {	13 18: SEQUENCE {
	<06 07>	<06 07>
	15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)	15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)

	skipping to change at line 746 ¶	skipping to change at line 750 ¶
	<06 03>	<06 03>
	33 3: OBJECT IDENTIFIER serialNumber (2 5 4 5)	33 3: OBJECT IDENTIFIER serialNumber (2 5 4 5)
	: (X.520 DN component)	: (X.520 DN component)
	<06 08>	<06 08>
	38 8: OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)	38 8: OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
	: (ANSI X9.62 ECDSA algorithm with SHA384)	: (ANSI X9.62 ECDSA algorithm with SHA384)
	: }	: }

	5.6. Require Specific Extensions and Attributes	5.6. Require Specific Extensions and Attributes


	The CSR is required to have an EC key, include a serial number,	The CSR is required to have an ECC public key, include a serial
	include a friendly name, include a favorite drink [favoritedrink]	number, include a friendly name, include a favorite drink
	[OID 0.9.2342.19200300.100.1.5], and use SHA512 as the hash algorithm	[favoritedrink] [OID 0.9.2342.19200300.100.1.5], and use SHA512 as
	within the signature.	the hash algorithm within the signature.

	5.6.1. Base64-Encoded Example	5.6.1. Base64-Encoded Example

	The Base64:	The Base64:

	MEUGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAjBgkq	MEUGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAjBgkq
	hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ=	hkiG9w0BCRQGCgmSJomT8ixkAQUGA1UEBQYIKoZIzj0EAwQ=

	5.6.2. ASN.1 DUMP Output	5.6.2. ASN.1 DUMP Output


	Provide a CSR with an EC key from sha521 and include your serial	Provide a CSR with an ECC public key from sha521 and include your
	number, friendly name, and favorite drink, and hash it with SHA512.	serial number, friendly name, and favorite drink, and hash it with
		SHA512.

	<30 45>	<30 45>
	0 69: SEQUENCE {	0 69: SEQUENCE {
	<06 09>	<06 09>
	2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)	2 9: OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
	: (PKCS #9)	: (PKCS #9)
	<30 12>	<30 12>
	13 18: SEQUENCE {	13 18: SEQUENCE {
	<06 07>	<06 07>
	15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)	15 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
	: (ANSI X9.62 public key type)	: (ANSI X9.62 public key type)
	<31 07>	<31 07>
	24 7: SET {	24 7: SET {
	<06 05>	<06 05>
	26 5: OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)	26 5: OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
	: (SECG (Certicom) named elliptic curve)	: (SECG (Certicom) named elliptic curve)
	: }	: }
	: }	: }
	<06 09>	<06 09>

	33 9: OBJECT IDENTIFIER friendlyName (for PKCS #12) (1 2 840 113549 1 9 20)	33 9: OBJECT IDENTIFIER friendlyName (for PKCS #12)
		(1 2 840 113549 1 9 20)
	: (PKCS #9 via PKCS #12)	: (PKCS #9 via PKCS #12)
	<06 0A>	<06 0A>
	44 10: OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5'	44 10: OBJECT IDENTIFIER '0 9 2342 19200300 100 1 5'
	<06 03>	<06 03>
	56 3: OBJECT IDENTIFIER serialNumber (2 5 4 5)	56 3: OBJECT IDENTIFIER serialNumber (2 5 4 5)
	: (X.520 DN component)	: (X.520 DN component)
	<06 08>	<06 08>
	61 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)	61 8: OBJECT IDENTIFIER ecdsaWithSHA512 (1 2 840 10045 4 3 4)
	: (ANSI X9.62 ECDSA algorithm with SHA512)	: (ANSI X9.62 ECDSA algorithm with SHA512)
	: }	: }

	skipping to change at line 947 ¶	skipping to change at line 953 ¶
	[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An	[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
	Autonomic Control Plane (ACP)", RFC 8994,	Autonomic Control Plane (ACP)", RFC 8994,
	DOI 10.17487/RFC8994, May 2021,	DOI 10.17487/RFC8994, May 2021,
	<https://www.rfc-editor.org/info/rfc8994>.	<https://www.rfc-editor.org/info/rfc8994>.

	[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,	[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
	and K. Watsen, "Bootstrapping Remote Secure Key	and K. Watsen, "Bootstrapping Remote Secure Key
	Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,	Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
	May 2021, <https://www.rfc-editor.org/info/rfc8995>.	May 2021, <https://www.rfc-editor.org/info/rfc8995>.


	[RFC9480] Brockhaus, H., von Oheimb, D., and J. Gray, "Certificate
	Management Protocol (CMP) Updates", RFC 9480,
	DOI 10.17487/RFC9480, November 2023,
	<https://www.rfc-editor.org/info/rfc9480>.

	[RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight	[RFC9483] Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
	Certificate Management Protocol (CMP) Profile", RFC 9483,	Certificate Management Protocol (CMP) Profile", RFC 9483,
	DOI 10.17487/RFC9483, November 2023,	DOI 10.17487/RFC9483, November 2023,
	<https://www.rfc-editor.org/info/rfc9483>.	<https://www.rfc-editor.org/info/rfc9483>.


		[RFC9810] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
		"Internet X.509 Public Key Infrastructure -- Certificate
		Management Protocol (CMP)", RFC 9810,
		DOI 10.17487/RFC9810, July 2025,
		<https://www.rfc-editor.org/info/rfc9810>.

		[RFC9811] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
		"Internet X.509 Public Key Infrastructure -- HTTP Transfer
		for the Certificate Management Protocol (CMP)", RFC 9811,
		DOI 10.17487/RFC9811, July 2025,
		<https://www.rfc-editor.org/info/rfc9811>.

	Appendix A. ASN.1 Module	Appendix A. ASN.1 Module

	This appendix provides an ASN.1 module [X.680] for the Certification	This appendix provides an ASN.1 module [X.680] for the Certification

	Request Information Template attribute, and it follows the	Request Information Template and Extension Request Template
	conventions established in [RFC5911], [RFC5912], and [RFC6268].	attributes, and it follows the conventions established in [RFC5911],
		[RFC5912], and [RFC6268].

	CRITemplateModule	CRITemplateModule
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	pkcs-9(9) smime(16) modules(0) id-mod-critemplate(82) }	pkcs-9(9) smime(16) modules(0) id-mod-critemplate(82) }

	DEFINITIONS IMPLICIT TAGS ::=	DEFINITIONS IMPLICIT TAGS ::=

	BEGIN	BEGIN

	IMPORTS -- from [RFC5912]	IMPORTS -- from [RFC5912]

	skipping to change at line 1050 ¶	skipping to change at line 1064 ¶
	subjectPublicKey BIT STRING OPTIONAL	subjectPublicKey BIT STRING OPTIONAL
	}	}

	id-aa-extensionReqTemplate OBJECT IDENTIFIER ::=	id-aa-extensionReqTemplate OBJECT IDENTIFIER ::=
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
	smime(16) aa(2) id-aa-extensionReqTemplate(62) }	smime(16) aa(2) id-aa-extensionReqTemplate(62) }

	-- like extensionRequest, but with OPTIONAL Extension extnValues	-- like extensionRequest, but with OPTIONAL Extension extnValues
	-- original definition was in PKCS#9 RFC 2985, Section 5.4.2	-- original definition was in PKCS#9 RFC 2985, Section 5.4.2
	at-extensionReqTemplate ATTRIBUTE ::= {	at-extensionReqTemplate ATTRIBUTE ::= {

	TYPE ExtensionReqTemplate IDENTIFIED BY id-aa-extensionReqTemplate }	TYPE ExtensionReqTemplate IDENTIFIED BY
		id-aa-extensionReqTemplate }

	ExtensionReqTemplate ::= ExtensionTemplates{{CertExtensions}}	ExtensionReqTemplate ::= ExtensionTemplates{{CertExtensions}}

	-- like Extensions, but with OPTIONAL extnValue	-- like Extensions, but with OPTIONAL extnValue
	ExtensionTemplates{EXTENSION:ExtensionSet} ::=	ExtensionTemplates{EXTENSION:ExtensionSet} ::=
	SEQUENCE SIZE (1..MAX) OF ExtensionTemplate{{ExtensionSet}}	SEQUENCE SIZE (1..MAX) OF ExtensionTemplate{{ExtensionSet}}

	-- like Extension, but with OPTIONAL extnValue	-- like Extension, but with OPTIONAL extnValue
	ExtensionTemplate{EXTENSION:ExtensionSet} ::= SEQUENCE {	ExtensionTemplate{EXTENSION:ExtensionSet} ::= SEQUENCE {
	extnID EXTENSION.&id({ExtensionSet}),	extnID EXTENSION.&id({ExtensionSet}),

End of changes. 23 change blocks.
	49 lines changed or deleted	64 lines changed or added
This html diff was produced by rfcdiff 1.48.