rfc9810v2.txt		rfc9810.txt
	skipping to change at line 648 ¶		skipping to change at line 648 ¶
	3.1.3. PKI Management Operations		3.1.3. PKI Management Operations
	The following diagram shows the relationship between the entities		The following diagram shows the relationship between the entities
	defined above in terms of the PKI management operations. The letters		defined above in terms of the PKI management operations. The letters
	in the diagram indicate "protocols" in the sense that a defined set		in the diagram indicate "protocols" in the sense that a defined set
	of PKI management messages can be sent along each of the lettered		of PKI management messages can be sent along each of the lettered
	lines.		lines.
	+---+ cert. publish +------------+ j		+---+ cert. publish +------------+ j
	| | <--------------------- | End Entity | <-------		| | <--------------------- | EE | <-------
	| C | g +------------+ "out-of-band"		| C | g +------------+ "out-of-band"
	| e | | ^ loading		| e | | ^ loading
	| r | | | initial		| r | | | initial
	| t | a | | b registration/		| t | a | | b registration/
	| | | | certification		| | | | certification
	| / | | | key pair recovery		| / | | | key pair recovery
	| | | | key pair update		| | | | key pair update
	| C | | | certificate update		| C | | | certificate update
	| R | PKI "USERS" V | revocation request		| R | PKI "USERS" V | revocation request
	| L | -------------------+-+-----+-+------+-+-------------------		| L | -------------------+-+-----+-+------+-+-------------------
	skipping to change at line 802 ¶		skipping to change at line 802 ¶
	Note that online protocols are not the only way of implementing the		Note that online protocols are not the only way of implementing the
	above operations. For all operations, there are offline methods of		above operations. For all operations, there are offline methods of
	achieving the same result, and this specification does not mandate		achieving the same result, and this specification does not mandate
	use of online protocols. For example, when hardware tokens are used,		use of online protocols. For example, when hardware tokens are used,
	many of the operations MAY be achieved as part of the physical token		many of the operations MAY be achieved as part of the physical token
	delivery.		delivery.
	Later sections define a set of standard messages supporting the above		Later sections define a set of standard messages supporting the above
	operations. Transfer protocols for conveying these exchanges in		operations. Transfer protocols for conveying these exchanges in
	various environments (e.g., offline: file-based; online: mail, HTTP		various environments (e.g., offline: file-based; online: email, HTTP
	[RFC9811], MQTT, and CoAP [RFC9482]) are beyond the scope of this		[RFC9811], MQTT, and CoAP [RFC9482]) are beyond the scope of this
	document and must be specified separately. Appropriate transfer		document and must be specified separately. Appropriate transfer
	protocols MUST be capable of delivering the CMP messages reliably.		protocols MUST be capable of delivering the CMP messages reliably.
	CMP provides inbuilt integrity protection and authentication. The		CMP provides inbuilt integrity protection and authentication. The
	information communicated unencrypted in CMP messages does not contain		information communicated unencrypted in CMP messages does not contain
	sensitive information endangering the security of the PKI when		sensitive information endangering the security of the PKI when
	intercepted. However, it might be possible for an eavesdropper to		intercepted. However, it might be possible for an eavesdropper to
	utilize the available information to gather confidential technical or		utilize the available information to gather confidential technical or
	business-critical information. Therefore, users should consider		business-critical information. Therefore, users should consider
	skipping to change at line 983 ¶		skipping to change at line 983 ¶
	* a confirmation message is recommended.		* a confirmation message is recommended.
	Note: An Initial Authentication Key (IAK) can be either a symmetric		Note: An Initial Authentication Key (IAK) can be either a symmetric
	key or an asymmetric private key with a certificate issued by another		key or an asymmetric private key with a certificate issued by another
	PKI trusted for this purpose. The establishment of such trust is out		PKI trusted for this purpose. The establishment of such trust is out
	of scope of this document.		of scope of this document.
	In terms of message flow, the basic authenticated scheme is as		In terms of message flow, the basic authenticated scheme is as
	follows:		follows:
	End entity RA/CA		EE RA/CA
	========== =============		========== =============
	out-of-band distribution of Initial Authentication		out-of-band distribution of Initial Authentication
	Key (IAK) and reference value (RA/CA -> EE)		Key (IAK) and reference value (RA/CA -> EE)
	Key generation		Key generation
	Creation of certification request		Creation of certification request
	Protect request with IAK		Protect request with IAK
	-----> certification request ----->		-----> certification request ----->
	verify request		verify request
	process request		process request
	create response		create response
	skipping to change at line 1934 ¶		skipping to change at line 1934 ¶
	successfully validated by Bob beforehand.		successfully validated by Bob beforehand.
	Bob generates a shared secret (ss) and the associated ciphertext		Bob generates a shared secret (ss) and the associated ciphertext
	(ct) using the KEM Encapsulate function with Alice's public KEM		(ct) using the KEM Encapsulate function with Alice's public KEM
	key (pk). Bob MUST NOT reuse the ss and ct for other PKI		key (pk). Bob MUST NOT reuse the ss and ct for other PKI
	management operations. From this data, Bob produces a		management operations. From this data, Bob produces a
	KemCiphertextInfo structure, including the KEM algorithm		KemCiphertextInfo structure, including the KEM algorithm
	identifier and the ciphertext (ct) and sends it to Alice in an		identifier and the ciphertext (ct) and sends it to Alice in an
	InfoTypeAndValue structure, as defined in Section 5.3.19.18.		InfoTypeAndValue structure, as defined in Section 5.3.19.18.
	Encapsulate(pk) -> (ct, ss)		Encapsulate(pk) -> (ct, ss)
	2. Alice decapsulates the shared secret (ss) from the ciphertext		2. Alice decapsulates the shared secret (ss) from the ciphertext
	(ct) using the KEM Decapsulate function and its private KEM key		(ct) using the KEM Decapsulate function and its private KEM key
	(sk).		(sk).
	Decapsulate(ct, sk) -> (ss)		Decapsulate(ct, sk) -> (ss)
	If the decapsulation operation outputs an error, any failInfo		If the decapsulation operation outputs an error, any failInfo
	field in an error response message SHALL contain the value		field in an error response message SHALL contain the value
	badMessageCheck and the PKI management operation SHALL be		badMessageCheck and the PKI management operation SHALL be
	terminated.		terminated.
	Alice derives the shared secret key (ssk) using a KDF. The		Alice derives the shared secret key (ssk) using a KDF. The
	shared secret (ss) is used as input key material for the KDF, and		shared secret (ss) is used as input key material for the KDF, and
	the value len is the desired output length of the KDF as required		the value len is the desired output length of the KDF as required
	by the MAC algorithm to be used for message protection. KDF,		by the MAC algorithm to be used for message protection. KDF,
	len, and MAC will be transferred to Bob in the protectionAlg		len, and MAC will be transferred to Bob in the protectionAlg
	KemBMParameter. The DER-encoded KemOtherInfo structure, as		KemBMParameter. The DER-encoded KemOtherInfo structure, as
	defined below, is used as context for the KDF.		defined below, is used as context for the KDF.
	KDF(ss, len, context)->(ssk)		KDF(ss, len, context)->(ssk)
	The shared secret key (ssk) is used for MAC-based protection by		The shared secret key (ssk) is used for MAC-based protection by
	Alice.		Alice.
	3. Bob derives the same shared secret key (ssk) using the KDF. Also		3. Bob derives the same shared secret key (ssk) using the KDF. Also
	here, the shared secret (ss) is used as input key material for		here, the shared secret (ss) is used as input key material for
	the KDF, the value len is the desired output length for the KDF,		the KDF, the value len is the desired output length for the KDF,
	and the DER-encoded KemOtherInfo structure constructed in the		and the DER-encoded KemOtherInfo structure constructed in the
	same way as on Alice's side is used as context for the KDF.		same way as on Alice's side is used as context for the KDF.
	KDF(ss, len, context)->(ssk)		KDF(ss, len, context)->(ssk)
	Bob uses the shared secret key (ssk) for verifying the MAC-based		Bob uses the shared secret key (ssk) for verifying the MAC-based
	protection of the message received and in this way authenticates		protection of the message received and in this way authenticates
	Alice.		Alice.
	This shared secret key (ssk) can be reused by Alice for MAC-based		This shared secret key (ssk) can be reused by Alice for MAC-based
	protection of further messages sent to Bob within the current PKI		protection of further messages sent to Bob within the current PKI
	management operation.		management operation.
	This approach employs the notation of KDF(IKM, L, info) as described		This approach employs the notation of KDF(IKM, L, info) as described
	skipping to change at line 2067 ¶		skipping to change at line 2067 ¶
	5.2. Common Data Structures		5.2. Common Data Structures
	Before specifying the specific types that may be placed in a PKIBody,		Before specifying the specific types that may be placed in a PKIBody,
	we define some data structures that are used in more than one case.		we define some data structures that are used in more than one case.
	5.2.1. Requested Certificate Contents		5.2.1. Requested Certificate Contents
	Various PKI management messages require that the originator of the		Various PKI management messages require that the originator of the
	message indicate some of the fields that are required to be present		message indicate some of the fields that are required to be present
	in a certificate. The CertTemplate structure allows an EE or RA to		in a certificate. The CertTemplate structure allows entities
	specify as many data fields as the structure wishes for the requested		requesting a certificate to specify the data fields that they want to
	certificate. The structure also allows an EE or RA to include any		be included. Typically, they are required to provide at least the
	other necessary data, such as the publicKey field, when it is		publicKey field. A CertTemplate structure is identical to a
	required for the certificate. A CertTemplate structure is identical		TBSCertificate structure (see [RFC5280]) but with all fields
	to a TBSCertificate structure (see [RFC5280]) but with all fields
	optional/situational.		optional/situational.
	Note: Even if the originator completely specifies the contents of a		Note: Even if the originator completely specifies the contents of a
	certificate it requires, a CA is free to modify fields within the		certificate it requires, a CA is free to modify fields within the
	certificate actually issued. If the modified certificate is		certificate actually issued. If the modified certificate is
	unacceptable to the requester, the requester MUST send back a		unacceptable to the requester, the requester MUST send back a
	certConf message that either does not include this certificate (via a		certConf message that either does not include this certificate (via a
	CertHash) or does include this certificate (via a CertHash) along		CertHash) or does include this certificate (via a CertHash) along
	with a status of "rejected". See Section 5.3.18 for the definition		with a status of "rejected". See Section 5.3.18 for the definition
	and use of CertHash and the certConf message.		and use of CertHash and the certConf message.
	skipping to change at line 2135 ¶		skipping to change at line 2134 ¶
	The use of the EncryptedValue structure has been deprecated in favor		The use of the EncryptedValue structure has been deprecated in favor
	of the EnvelopedData structure. Therefore, it is RECOMMENDED to use		of the EnvelopedData structure. Therefore, it is RECOMMENDED to use
	EnvelopedData.		EnvelopedData.
	Note: The EncryptedKey structure defined in CRMF [RFC4211] is used		Note: The EncryptedKey structure defined in CRMF [RFC4211] is used
	here, which makes the update backward compatible. Using the new		here, which makes the update backward compatible. Using the new
	syntax with the untagged default choice EncryptedValue is bits-on-		syntax with the untagged default choice EncryptedValue is bits-on-
	the-wire compatible with the old syntax.		the-wire compatible with the old syntax.
	To indicate support for EnvelopedData, the pvno cmp2021 has been		To indicate support for EnvelopedData, the pvno cmp2021 has been
	introduced. Details on the usage of the pvno are described in		introduced. Details on the usage of the protocol version number are
	Section 7.		described in Section 7.
	The EnvelopedData structure is RECOMMENDED to be used in CMP to		The EnvelopedData structure is RECOMMENDED to be used in CMP to
	transport a private key, certificate, POP challenge, or revocation		transport a private key, certificate, POP challenge, or revocation
	passphrase in encrypted form as follows:		passphrase in encrypted form as follows:
	* It contains only one RecipientInfo structure because the content		* It contains only one RecipientInfo structure because the content
	is encrypted only for one recipient.		is encrypted only for one recipient.
	* It may contain a private key in the AsymmetricKeyPackage structure		* It may contain a private key in the AsymmetricKeyPackage structure
	(which is placed in the encryptedContentInfo field), as defined in		(which is placed in the encryptedContentInfo field), as defined in
	skipping to change at line 3372 ¶		skipping to change at line 3371 ¶
	(empty pending list) V V | pollRep		(empty pending list) V V | pollRep
	END <---- Send certConf Send pollReq---------->Wait		END <---- Send certConf Send pollReq---------->Wait
	| ^ ^ |		| ^ ^ |
	| | | |		| | | |
	+-----------------+ +---------------+		+-----------------+ +---------------+
	(pending list)		(pending list)
	In the following exchange, the EE is enrolling for two certificates		In the following exchange, the EE is enrolling for two certificates
	in one request.		in one request.
	Step# End Entity PKI		Step# EE PKI
	---------------------------------------------------------------------		---------------------------------------------------------------------
	1 format ir		1 format ir
	2 --> ir -->		2 --> ir -->
	3 handle ir		3 handle ir
	4 manual intervention is		4 manual intervention is
	required for both certs		required for both certs
	5 <-- ip <--		5 <-- ip <--
	6 process ip		6 process ip
	7 format pollReq		7 format pollReq
	8 --> pollReq -->		8 --> pollReq -->
	skipping to change at line 3443 ¶		skipping to change at line 3442 ¶
	pollRep other response |		pollRep other response |
	v		v
	Handle response		Handle response
	|		|
	v		v
	End		End
	In the following exchange, the EE is sending a general message		In the following exchange, the EE is sending a general message
	request, and the response is delayed by the server.		request, and the response is delayed by the server.
	Step# End Entity PKI		Step# EE PKI
	---------------------------------------------------------------------		---------------------------------------------------------------------
	1 format genm		1 format genm
	2 --> genm -->		2 --> genm -->
	3 handle genm		3 handle genm
	4 delay in response is necessary		4 delay in response is necessary
	5 format error message "waiting"		5 format error message "waiting"
	with certReqId set to -1		with certReqId set to -1
	6 <-- error <--		6 <-- error <--
	7 process error		7 process error
	8 format pollReq		8 format pollReq
	skipping to change at line 3584 ¶		skipping to change at line 3583 ¶
	The CA administrator for the responder identifies the CA it wants		The CA administrator for the responder identifies the CA it wants
	to cross-certify and the responder CA equipment generates an		to cross-certify and the responder CA equipment generates an
	authorization code. The responder CA administrator passes this		authorization code. The responder CA administrator passes this
	authorization code by out-of-band means to the requester CA		authorization code by out-of-band means to the requester CA
	administrator. The requester CA administrator enters the		administrator. The requester CA administrator enters the
	authorization code at the requester CA in order to initiate the		authorization code at the requester CA in order to initiate the
	online exchange.		online exchange.
	The authorization code is used for authentication and integrity		The authorization code is used for authentication and integrity
	purposes. This is done by generating a symmetric key based on the		purposes. This is done by generating a symmetric key based on the
	authorization code and using the symmetric key for generating		authorization code and using the symmetric key for generating MACs
	MACs) on all messages exchanged. (Authentication may		on all messages exchanged. (Authentication may alternatively be
	alternatively be done using signatures instead of MACs, if the CAs		done using signatures instead of MACs, if the CAs are able to
	are able to retrieve and validate the required public keys by some		retrieve and validate the required public keys by some means, such
	means, such as an out-of-band hash comparison.)		as an out-of-band hash comparison.)
	The requester CA initiates the exchange by generating a cross-		The requester CA initiates the exchange by generating a cross-
	certification request (ccr) with a fresh random number (requester		certification request (ccr) with a fresh random number (requester
	random number). The requester CA then sends the ccr message to		random number). The requester CA then sends the ccr message to
	the responder CA. The fields in this message are protected from		the responder CA. The fields in this message are protected from
	modification with a MAC based on the authorization code.		modification with a MAC based on the authorization code.
	Upon receipt of the ccr message, the responder CA validates the		Upon receipt of the ccr message, the responder CA validates the
	message and the MAC, saves the requester random number, and		message and the MAC, saves the requester random number, and
	generates its own random number (responder random number). It		generates its own random number (responder random number). It
	skipping to change at line 3721 ¶		skipping to change at line 3720 ¶
	If a client knows the protocol version(s) supported by the server		If a client knows the protocol version(s) supported by the server
	(e.g., from a previous PKIMessage exchange or via some out-of-band		(e.g., from a previous PKIMessage exchange or via some out-of-band
	means), then it MUST send a PKIMessage with the highest version		means), then it MUST send a PKIMessage with the highest version
	supported by both it and the server. If a client does not know what		supported by both it and the server. If a client does not know what
	version(s) the server supports, then it MUST send a PKIMessage using		version(s) the server supports, then it MUST send a PKIMessage using
	the highest version it supports with the following exception: Version		the highest version it supports with the following exception: Version
	cmp2021 SHOULD only be used if cmp2021 syntax is needed for the		cmp2021 SHOULD only be used if cmp2021 syntax is needed for the
	request being sent or for the expected response.		request being sent or for the expected response.
	Note: Using cmp2000 as the default pvno is done to avoid extra		Note: Using cmp2000 as the default pvno value is done to avoid extra
	message exchanges for version negotiation and to foster compatibility		message exchanges for version negotiation and to foster compatibility
	with cmp2000 implementations. Version cmp2021 syntax is only needed		with cmp2000 implementations. Version cmp2021 syntax is only needed
	if a message exchange uses EnvelopedData, hashAlg (in CertStatus),		if a message exchange uses EnvelopedData, hashAlg (in CertStatus),
	POPOPrivKey with agreeMAC, or ckuann with RootCaKeyUpdateContent.		POPOPrivKey with agreeMAC, or ckuann with RootCaKeyUpdateContent.
	If a server receives a message with a version that it supports, then		If a server receives a message with a version that it supports, then
	the version of the response message MUST be the same as the received		the version of the response message MUST be the same as the received
	version. If a server receives a message with a version higher or		version. If a server receives a message with a version higher or
	lower than it supports, then it MUST send back an ErrorMsg with the		lower than it supports, then it MUST send back an ErrorMsg with the
	unsupportedVersion bit set (in the failureInfo field of the		unsupportedVersion bit set (in the failureInfo field of the
	skipping to change at line 3751 ¶		skipping to change at line 3750 ¶
	7.1. Supporting RFC 2510 Implementations		7.1. Supporting RFC 2510 Implementations
	[RFC2510] did not specify the behavior of implementations receiving		[RFC2510] did not specify the behavior of implementations receiving
	versions they did not understand since there was only one version in		versions they did not understand since there was only one version in
	existence. With the introduction of the revision in [RFC4210], the		existence. With the introduction of the revision in [RFC4210], the
	following versioning behavior is recommended.		following versioning behavior is recommended.
	7.1.1. Clients Talking to RFC 2510 Servers		7.1.1. Clients Talking to RFC 2510 Servers
	If, after sending a message with a pvno higher than cmp1999, a client		If, after sending a message with a pvno value higher than cmp1999, a
	receives an ErrorMsgContent with a version of cmp1999, then it MUST		client receives an ErrorMsgContent with a version of cmp1999, then it
	abort the current transaction.		MUST abort the current transaction.
	If a client receives a non-error PKIMessage with a version of		If a client receives a non-error PKIMessage with a version of
	cmp1999, then it MAY decide to continue the transaction (if the		cmp1999, then it MAY decide to continue the transaction (if the
	transaction hasn't finished) using the semantics described in		transaction hasn't finished) using the semantics described in
	[RFC2510]. If it does not choose to do so and the transaction is not		[RFC2510]. If it does not choose to do so and the transaction is not
	finished, then it MUST abort the transaction and send an		finished, then it MUST abort the transaction and send an
	ErrorMsgContent with a version of cmp1999.		ErrorMsgContent with a version of cmp1999.
	7.1.2. Servers Receiving Version cmp1999 PKIMessages		7.1.2. Servers Receiving Version cmp1999 PKIMessages
	skipping to change at line 3893 ¶		skipping to change at line 3892 ¶
	800-90A Rev.1 [NIST.SP.800_90Ar1], BSI AIS 31 V2.0 [AIS31], and other		800-90A Rev.1 [NIST.SP.800_90Ar1], BSI AIS 31 V2.0 [AIS31], and other
	specifications offer valuable guidance in this area.		specifications offer valuable guidance in this area.
	If shared secret information is generated by a cryptographically		If shared secret information is generated by a cryptographically
	secure random number generator (CSRNG), it is safe to assume that the		secure random number generator (CSRNG), it is safe to assume that the
	entropy of the shared secret information equals its bit length. If		entropy of the shared secret information equals its bit length. If
	no CSRNG is used, the entropy of shared secret information depends on		no CSRNG is used, the entropy of shared secret information depends on
	the details of the generation process and cannot be measured securely		the details of the generation process and cannot be measured securely
	after it has been generated. If user-generated passwords are used as		after it has been generated. If user-generated passwords are used as
	shared secret information, their entropy cannot be measured.		shared secret information, their entropy cannot be measured.
	Passwords generated from user generated entropy are typically		Passwords generated from user-supplied entropy are typically
	insufficient for protected delivery of centrally generated keys or		insufficient for protected delivery of centrally generated keys or
	trust anchors.		trust anchors.
	If the entropy of shared secret information protecting the delivery		If the entropy of shared secret information protecting the delivery
	of a centrally generated key pair is known, it should not be less		of a centrally generated key pair is known, it should not be less
	than the security strength of that key pair; if the shared secret		than the security strength of that key pair; if the shared secret
	information is reused for different key pairs, the security of the		information is reused for different key pairs, the security of the
	shared secret information should exceed the security strength of each		shared secret information should exceed the security strength of each
	individual key pair.		individual key pair.
	skipping to change at line 4007 ¶		skipping to change at line 4006 ¶
	IANA has added the following entry in the "SMI Security for PKIX CMP		IANA has added the following entry in the "SMI Security for PKIX CMP
	Information Types" registry within the SMI Numbers registry group		Information Types" registry within the SMI Numbers registry group
	(see <https://www.iana.org/assignments/smi-numbers>) [RFC7299]:		(see <https://www.iana.org/assignments/smi-numbers>) [RFC7299]:
	Decimal: 24		Decimal: 24
	Description: id-it-KemCiphertextInfo		Description: id-it-KemCiphertextInfo
	Reference: RFC 9810		Reference: RFC 9810
	Note that the new OID 1.2.840.113533.7.66.16 was registered by		Note that the new OID 1.2.840.113533.7.66.16 was registered by
	Entrust, and not by IANA, for id-KemBasedMac in the arch		Entrust, and not by IANA, for id-KemBasedMac in the arc
	1.2.840.113533.7.66. This was done to match the previous		1.2.840.113533.7.66. This was done to match the previous
	registrations for id-PasswordBasedMac and id-DHBasedMac, which are		registrations for id-PasswordBasedMac and id-DHBasedMac, which are
	also on the Entrust private arc.		also on the Entrust private arc.
	All existing references to [RFC2510], [RFC4210], and [RFC9480] at		All existing references to [RFC2510], [RFC4210], and [RFC9480] at
	<https://www.iana.org/assignments/smi-numbers> except those in the		<https://www.iana.org/assignments/smi-numbers> except those in the
	"SMI Security for PKIX Module Identifier" registry have been replaced		"SMI Security for PKIX Module Identifier" registry have been replaced
	with references to this document.		with references to this document.
	10. References		10. References
	skipping to change at line 4477 ¶		skipping to change at line 4476 ¶
	* certificate request		* certificate request
	* key update		* key update
	C.1. General Rules for Interpretation of These Profiles		C.1. General Rules for Interpretation of These Profiles
	1. Where OPTIONAL or DEFAULT fields are not mentioned in individual		1. Where OPTIONAL or DEFAULT fields are not mentioned in individual
	profiles, they SHOULD be absent from the relevant message (i.e.,		profiles, they SHOULD be absent from the relevant message (i.e.,
	a receiver can validly reject a message containing such fields as		a receiver can validly reject a message containing such fields as
	being syntactically incorrect). Mandatory fields are not		being syntactically incorrect). Mandatory fields are not
	mentioned if they have an obvious value. The pvno MUST be set as		mentioned if they have an obvious value. The protocol version
	specified in Section 7).		number MUST be set as specified in Section 7).
	2. Where structures occur in more than one message, they are		2. Where structures occur in more than one message, they are
	separately profiled as appropriate.		separately profiled as appropriate.
	3. The algorithmIdentifiers from PKIMessage structures are profiled		3. The algorithmIdentifiers from PKIMessage structures are profiled
	separately.		separately.
	4. A "special" X.500 DN is called the "NULL-DN"; this means a DN		4. A "special" X.500 DN is called the "NULL-DN"; this means a DN
	containing a zero-length SEQUENCE OF RelativeDistinguishedNames		containing a zero-length SEQUENCE OF RelativeDistinguishedNames
	(its DER encoding is then '3000'H).		(its DER encoding is then '3000'H).
	skipping to change at line 4588 ¶		skipping to change at line 4587 ¶
	Preconditions:		Preconditions:
	1. The EE can authenticate the CA's signature based on out-of-band		1. The EE can authenticate the CA's signature based on out-of-band
	means.		means.
	2. The EE and the CA share a symmetric MACing key.		2. The EE and the CA share a symmetric MACing key.
	Message Flow:		Message Flow:
	Step# End entity PKI		Step# EE PKI
	---------------------------------------------------------------------		---------------------------------------------------------------------
	1 format ir		1 format ir
	2 --> ir -->		2 --> ir -->
	3 handle ir		3 handle ir
	4 format ip		4 format ip
	5 <-- ip <--		5 <-- ip <--
	6 handle ip		6 handle ip
	7 format certConf		7 format certConf
	8 --> certConf -->		8 --> certConf -->
	9 handle certConf		9 handle certConf
	skipping to change at line 5007 ¶		skipping to change at line 5006 ¶
	The EE sends a general message to the PKI requesting details that		The EE sends a general message to the PKI requesting details that
	will be required for later PKI management operations. The RA/CA		will be required for later PKI management operations. The RA/CA
	responds with a general response. If an RA generates the response,		responds with a general response. If an RA generates the response,
	then it will simply forward the equivalent message that it previously		then it will simply forward the equivalent message that it previously
	received from the CA, with the possible addition of certificates to		received from the CA, with the possible addition of certificates to
	the extraCerts fields of the PKIMessage. A confirmation message is		the extraCerts fields of the PKIMessage. A confirmation message is
	not required from the EE.		not required from the EE.
	Message Flows:		Message Flows:
	Step# End entity PKI		Step# EE PKI
	---------------------------------------------------------------------		---------------------------------------------------------------------
	1 format genm		1 format genm
	2 --> genm -->		2 --> genm -->
	3 handle genm		3 handle genm
	4 produce genp		4 produce genp
	5 <-- genp <--		5 <-- genp <--
	6 handle genp		6 handle genp
	genM:		genM:
End of changes. 19 change blocks.
	32 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.48.