draft-ietf-sidrops-rtr-keying-00.txt		draft-ietf-sidrops-rtr-keying-01.txt
	Network Working Group R. Bush		Network Working Group R. Bush
	Internet-Draft IIJ Lab / Dragon Research Lab		Internet-Draft IIJ Lab / Dragon Research Lab
	Intended status: Standards Track S. Turner		Intended status: Standards Track S. Turner
	Expires: March 25, 2019 sn3rd		Expires: June 7, 2019 sn3rd
	K. Patel		K. Patel
	Arrcus, Inc.		Arrcus, Inc.
	September 21, 2018		December 4, 2018
	Router Keying for BGPsec		Router Keying for BGPsec
	draft-ietf-sidrops-rtr-keying-00		draft-ietf-sidrops-rtr-keying-01
	Abstract		Abstract
	BGPsec-speaking routers are provisioned with private keys in order to		BGPsec-speaking routers are provisioned with private keys in order to
	sign BGPsec announcements. The corresponding public keys are		sign BGPsec announcements. The corresponding public keys are
	published in the global Resource Public Key Infrastructure, enabling		published in the global Resource Public Key Infrastructure, enabling
	verification of BGPsec messages. This document describes two methods		verification of BGPsec messages. This document describes two methods
	of generating the public-private key-pairs: router-driven and		of generating the public-private key-pairs: router-driven and
	operator-driven.		operator-driven.
	skipping to change at page 3, line 10 ¶		skipping to change at page 3, line 10 ¶
	BGPsec-speaking routers are provisioned with private keys, which		BGPsec-speaking routers are provisioned with private keys, which
	allow them to digitally sign BGPsec announcements. To verify the		allow them to digitally sign BGPsec announcements. To verify the
	signature, the public key, in the form of a certificate [RFC8209], is		signature, the public key, in the form of a certificate [RFC8209], is
	published in the Resource Public Key Infrastructure (RPKI). This		published in the Resource Public Key Infrastructure (RPKI). This
	document describes provisioning of BGPsec-speaking routers with the		document describes provisioning of BGPsec-speaking routers with the
	appropriate public-private key-pairs. There are two sub-methods,		appropriate public-private key-pairs. There are two sub-methods,
	router-driven and operator-driven.		router-driven and operator-driven.
	These two sub-methods differ in where the keys are generated: on the		These two sub-methods differ in where the keys are generated: on the
	router in the router-driven method, and elsewhere in the operator-		router in the router-driven method, and elsewhere in the
	driven method. Routers are required to support at least one of the		operator-driven method. Routers are required to support at least one
	methods in order to work in various deployment environments. Some		of the methods in order to work in various deployment environments.
	routers may not allow the private key to be off-loaded while others		Some routers may not allow the private key to be off-loaded while
	may. While off-loading private keys would ease swapping of routing		others may. While off-loading private keys would ease swapping of
	engines, exposure of private keys is a well known security risk.		routing engines, exposure of private keys is a well known security
			risk.
	In the operator-driven method, the operator generates the private/		In the operator-driven method, the operator generates the
	public key-pair and sends it to the router.		private/public key-pair and sends it to the router.
	In the router-driven method, the router generates its own public/		In the router-driven method, the router generates its own
	private key-pair.		public/private key-pair.
	The router-driven model mirrors the model used by traditional PKI		The router-driven model mirrors the model used by traditional PKI
	subscribers; the private key never leaves trusted storage (e.g.,		subscribers; the private key never leaves trusted storage (e.g.,
	Hardware Security Module). This is by design and supports classic		Hardware Security Module). This is by design and supports classic
	PKI Certification Policies for (often human) subscribers which		PKI Certification Policies for (often human) subscribers which
	require the private key only ever be controlled by the subscriber to		require the private key only ever be controlled by the subscriber to
	ensure that no one can impersonate the subscriber. For non-humans,		ensure that no one can impersonate the subscriber. For non-humans,
	this model does not always work. For example, when an operator wants		this model does not always work. For example, when an operator wants
	to support hot-swappable routers the same private key needs to be		to support hot-swappable routers, the same private key needs to be
	installed in the soon-to-be online router that was used by the the		installed in the soon-to-be online router that was used by the the
	soon-to-be offline router. This motivated the operator-driven model.		soon-to-be offline router. This motivated the operator-driven model.
	The remainder of this document describes how operators can use the		The remainder of this document describes how operators can use the
	two methods to provision new and existing routers. The methods		two methods to provision new and existing routers. The methods
	described involve the operator configuring the two end points (i.e.,		described involve the operator configuring the two end points (i.e.,
	the management station and the router) and acting as the		the management station and the router) and acting as the
	intermediary. Section 7 describes a method that requires more		intermediary. Section 8 describes a method that requires more
	capable routers.		capable routers.
	Useful References: [RFC8205] describes gritty details, [RFC8209]		Useful References: [RFC8205] describes gritty details, [RFC8209]
	specifies the format for the PKCS#10 certification request, and		specifies the format for the PKCS#10 certification request, and
	[RFC8208] specifies the algorithms used to generate the PKCS#10's		[RFC8208] specifies the algorithms used to generate the PKCS#10's
	signature.		signature.
	2. Management / Router Communication		2. Management / Router Communication
	Operators are free to use either the router-driven or operator-driven		Operators are free to use either the router-driven or operator-driven
	skipping to change at page 4, line 41 ¶		skipping to change at page 4, line 42 ¶
	The operator also configures the Autonomous System (AS) number to be		The operator also configures the Autonomous System (AS) number to be
	used in the generated router certificate. This may be the sole AS		used in the generated router certificate. This may be the sole AS
	configured on the router, or an operator choice if the router is		configured on the router, or an operator choice if the router is
	configured with multiple ASs. A router with multiple ASs can be		configured with multiple ASs. A router with multiple ASs can be
	configured with multiple router certificates by following the process		configured with multiple router certificates by following the process
	of this document for each desired certificate.		of this document for each desired certificate.
	The operator configures or extracts from the router the BGP		The operator configures or extracts from the router the BGP
	Identifier [RFC4271] to be used in the generated router certificate.		Identifier [RFC4271] to be used in the generated router certificate.
	In the case where the operator has chosen not to use unique per-		In the case where the operator has chosen not to use unique
	router certificates, a BGP Identifier of 0 may be used.		per-router certificates, a BGP Identifier of 0 may be used.
	5. Generate PKCS#10		5. Generate PKCS#10
	The private key, and hence the PKCS#10 certification request, which		The private key, and hence the PKCS#10 certification request, which
	is sometimes referred to as a Certificate Signing Request (CSR), may		is sometimes referred to as a Certificate Signing Request (CSR), may
	be generated by the router or by the operator.		be generated by the router or by the operator.
	The PKCS#10 request SHOULD be saved to enable verifying that the		The PKCS#10 request SHOULD be saved to enable verifying that the
	returned public key in the certificate corresponds to the private		returned public key in the certificate corresponds to the private
	used to generate the signature on the CSR.		used to generate the signature on the CSR.
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 45 ¶
	private key into the router over the protected channel. Beware that		private key into the router over the protected channel. Beware that
	experience has shown that copy and paste from a management station to		experience has shown that copy and paste from a management station to
	a router can be unreliable for long texts.		a router can be unreliable for long texts.
	The operator then creates and signs the PKCS#10 certification request		The operator then creates and signs the PKCS#10 certification request
	with the private key; the operator includes the chosen AS number and		with the private key; the operator includes the chosen AS number and
	the BGP Identifier when it sends the CSR to the CA.		the BGP Identifier when it sends the CSR to the CA.
	Even if the operator cannot extract the private key from the router,		Even if the operator cannot extract the private key from the router,
	this signature still provides a linkage between a private key and a		this signature still provides a linkage between a private key and a
	router. That is the operator can verify the proof of possession		router. That is, the operator can verify the proof of possession
	(POP), as required by [RFC6484].		(POP), as required by [RFC6484].
	5.2.1. Using PKCS#8 to Transfer Private Key		5.2.1. Using PKCS#8 to Transfer Private Key
	A private key can be encapsulated in a PKCS#8 Asymmetric Key Package		A private key can be encapsulated in a PKCS#8 Asymmetric Key Package
	[RFC5958] and should be further encapsulated in Cryptographic Message		[RFC5958] and should be further encapsulated in Cryptographic Message
	Syntax (CMS) SignedData [RFC5652] and signed with the AS's End Entity		Syntax (CMS) SignedData [RFC5652] and signed with the AS's End Entity
	(EE) private key.		(EE) private key.
	The router SHOULD verify the signature of the encapsulated PKCS#8 to		The router SHOULD verify the signature of the encapsulated PKCS#8 to
	skipping to change at page 7, line 19 ¶		skipping to change at page 7, line 20 ¶
	key in the returned certificate. If the router did not store the		key in the returned certificate. If the router did not store the
	PKCS#10, it can check this correspondence by generating a signature		PKCS#10, it can check this correspondence by generating a signature
	on any data and then verifying the signature using the returned		on any data and then verifying the signature using the returned
	certificate. The router SHOULD inform the operator whether it		certificate. The router SHOULD inform the operator whether it
	successfully received the certificate and whether or not the keys		successfully received the certificate and whether or not the keys
	correspond; the mechanism is out of scope.		correspond; the mechanism is out of scope.
	The router SHOULD also verify that the returned certificate validates		The router SHOULD also verify that the returned certificate validates
	back to the installed TA Certificate, i.e., the entire chain from the		back to the installed TA Certificate, i.e., the entire chain from the
	installed TA Certificate through subordinate CAs to the BGPsec		installed TA Certificate through subordinate CAs to the BGPsec
	certificate validate. To perform this verification the CA		certificate validate. To perform this verification, the CA
	certificate chain needs to be returned along with the router's		certificate chain needs to be returned along with the router's
	certificate in the PKCS#7 certs-only message. The router SHOULD		certificate in the PKCS#7 certs-only message. The router SHOULD
	inform the operator whether or not the signature validates to a trust		inform the operator whether or not the signature validates to a trust
	anchor; this notification mechanism is out of scope.		anchor; this notification mechanism is out of scope.
	NOTE: The signature on the PKCS#8 and Certificate need not be made by		NOTE: The signature on the PKCS#8 and Certificate need not be made by
	the same entity. Signing the PKCS#8, permits more advanced		the same entity. Signing the PKCS#8, permits more advanced
	configurations where the entity that generates the keys is not the		configurations where the entity that generates the keys is not the
	direct CA.		direct CA.
	8. Advanced Deployment Scenarios		8. Advanced Deployment Scenarios
	More PKI-capable routers can take advantage of this increased		More PKI-capable routers can take advantage of this increased
	functionality and lighten the operator's burden. Typically, these		functionality and lighten the operator's burden. Typically, these
	routers include either pre-installed manufacturer-generated		routers include either pre-installed manufacturer-generated
	certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed		certificates (e.g., IEEE 802.1 AR [802.1AR]) or pre-installed
	manufacturer-generated Pre-Shared Keys (PSK) as well as PKI-		manufacturer-generated Pre-Shared Keys (PSK) as well as
	enrollment functionality and transport protocol, e.g., CMC's "Secure		PKI-enrollment functionality and transport protocol, e.g., CMC's
	Transport" [RFC7030] or the original CMC transport protocol's		"Secure Transport" [RFC7030] or the original CMC transport protocol's
	[RFC5273]. When the operator first establishes a protected channel		[RFC5273]. When the operator first establishes a protected channel
	between the management system and the router, this pre-installed key		between the management system and the router, this pre-installed key
	material is used to authenticate the router.		material is used to authenticate the router.
	The operator burden shifts here to include:		The operator burden shifts here to include:
	1. Securely communicating the router's authentication material to		1. Securely communicating the router's authentication material to
	the CA prior to operator initiating the router's CSR. CAs use		the CA prior to operator initiating the router's CSR. CAs use
	authentication material to determine whether the router is		authentication material to determine whether the router is
	eligible to receive a certificate. Authentication material at a		eligible to receive a certificate. Authentication material at a
	skipping to change at page 8, line 28 ¶		skipping to change at page 8, line 30 ¶
	there is no need for the operator to retrieve the PKCS#10		there is no need for the operator to retrieve the PKCS#10
	certification request from the router as in Section 5 or return the		certification request from the router as in Section 5 or return the
	PKCS#7 certs-only message to the router as in Section 6. Note that		PKCS#7 certs-only message to the router as in Section 6. Note that
	the checks performed by the router in Section 7, namely extracting		the checks performed by the router in Section 7, namely extracting
	the certificate from the PKCS#7 certs-only message, verifying the		the certificate from the PKCS#7 certs-only message, verifying the
	public key corresponds to the private key, and that the returned		public key corresponds to the private key, and that the returned
	certificate validated back to an installed trust anchor, SHOULD be		certificate validated back to an installed trust anchor, SHOULD be
	performed. Likewise, the router SHOULD notify the operator if any of		performed. Likewise, the router SHOULD notify the operator if any of
	these fail, but this notification mechanism is out of scope.		these fail, but this notification mechanism is out of scope.
	When a router is so configured the communication with the CA SHOULD		When a router is so configured, the communication with the CA SHOULD
	be automatically re-established by the router at future times to		be automatically re-established by the router at future times to
	renew or rekey the certificate automatically when necessary (See		renew or rekey the certificate automatically when necessary (See
	Section 8). This further reduces the tasks required of the operator.		Section 9). This further reduces the tasks required of the operator.
	9. Key Management		9. Key Management
	Key management does not only include key generation, key		Key management does not only include key generation, key
	provisioning, certificate issuance, and certificate distribution. It		provisioning, certificate issuance, and certificate distribution. It
	also includes assurance of key validity, key roll-over, and key		also includes assurance of key validity, key roll-over, and key
	preservation during router replacement. All of these		preservation during router replacement. All of these
	responsibilities persist for as long as the operator wishes to		responsibilities persist for as long as the operator wishes to
	operate the BGPsec-speaking router.		operate the BGPsec-speaking router.
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 23 ¶
	3. The RPKI CA warns the operator of pending expiration, and/or		3. The RPKI CA warns the operator of pending expiration, and/or
	4. The operator uses some other kind of automated process to search		4. The operator uses some other kind of automated process to search
	for and track the expiry times of router certificates.		for and track the expiry times of router certificates.
	It is advisable that expiration warnings happen well in advance of		It is advisable that expiration warnings happen well in advance of
	the actual expiry time.		the actual expiry time.
	Regardless of the technique used to track router certificate expiry		Regardless of the technique used to track router certificate expiry
	times, it is advisable to notify additional operators in the same		times, it is advisable to notify additional operators in the same
	organization as the expiry time approaches thereby ensuring that the		organization as the expiry time approaches, thereby ensuring that the
	forgetfulness of one operator does not affect the entire		forgetfulness of one operator does not affect the entire
	organization.		organization.
	Depending on inter-operator relationship, it may be helpful to notify		Depending on inter-operator relationship, it may be helpful to notify
	a peer operator that one or more of their certificates are about to		a peer operator that one or more of their certificates are about to
	expire.		expire.
	9.2. Key Roll-Over		9.2. Key Roll-Over
	Routers that support multiple private keys also greatly increase the		Routers that support multiple private keys also greatly increase the
	skipping to change at page 9, line 44 ¶		skipping to change at page 9, line 46 ¶
	expiration of the operational key. Obviously, the router needs to		expiration of the operational key. Obviously, the router needs to
	know when to start using the new key. Once the new key is being		know when to start using the new key. Once the new key is being
	used, having the already distributed certificate ensures continuous		used, having the already distributed certificate ensures continuous
	operation.		operation.
	More information on how to proceed with a Key Roll-Over is described		More information on how to proceed with a Key Roll-Over is described
	in [I-D.sidrops-bgpsec-rollover].		in [I-D.sidrops-bgpsec-rollover].
	9.3. Key Revocation		9.3. Key Revocation
	Certain unfortunate circumstances may occur causing a need to revoke		In certain circumstances, a router's BGPsec certificate may need to
	a router's BGPsec certificate. When this occurs, the operator needs		be revoked. When this occurs, the operator needs to use the RPKI CA
	to use the RPKI CA system to revoke the certificate by placing the		system to revoke the certificate by placing the router's BGPsec
	router's BGPsec certificate on the Certificate Revocation List (CRL)		certificate on the Certificate Revocation List (CRL) as well as
	as well as re-keying the router's certificate.		re-keying the router's certificate.
	When an active router key is to be revoked, the process of requesting		When an active router key is to be revoked, the process of requesting
	the CA to revoke, the process of the CA actually revoking the		the CA to revoke, the process of the CA actually revoking the
	router's certificate, and then the process of re-keying/renewing the		router's certificate, and then the process of re-keying/renewing the
	router's certificate, (possibly distributing a new key and		router's certificate, (possibly distributing a new key and
	certificate to the router), and distributing the status takes time		certificate to the router), and distributing the status, takes time
	during which the operator must decide how they wish to maintain		during which the operator must decide how they wish to maintain
	continuity of operations, with or without the compromised private		continuity of operations, with or without the compromised private
	key, or whether they wish to bring the router offline to address the		key, or whether they wish to bring the router offline to address the
	compromise.		compromise.
	Keeping the router operational and BGPsec-speaking is the ideal goal,		Keeping the router operational and BGPsec-speaking is the ideal goal;
	but if operational practices do not allow this then reconfiguring the		but, if operational practices do not allow this, then reconfiguring
	router to disable BGPsec is likely preferred to bringing the router		the router to disable BGPsec is likely preferred to bringing the
	offline.		router offline.
	Routers which support more than one private key, where one is		Routers which support more than one private key, where one is
	operational and other(s) are soon-to-be-operational, facilitate		operational and other(s) are soon-to-be-operational, facilitate
	revocation events because the operator can configure the router to		revocation events because the operator can configure the router to
	make a soon-to-be-operational key operational, request revocation of		make a soon-to-be-operational key operational, request revocation of
	the compromised key, and then make a next generation soon-to-be-		the compromised key, and then make a next generation
	operational key, all hopefully without needing to take offline or		soon-to-be-operational key. Hopefully, all this can be done without
	reboot the router. For routers which support only one operational		needing to take offline or reboot the router. For routers which
	key, the operators should create or install the new private key, and		support only one operational key, the operators should create or
	then request revocation of the certificate corresponding to the		install the new private key, and then request revocation of the
	compromised private key.		certificate corresponding to the compromised private key.
	9.4. Router Replacement		9.4. Router Replacement
	Currently routers often generate private keys for uses such as SSH,		Currently routers often generate private keys for uses such as SSH,
	and the private keys may not be seen or off-loaded from the router.		and the private keys may not be seen or off-loaded from the router.
	While this is good security, it creates difficulties when a routing		While this is good security, it creates difficulties when a routing
	engine or whole router must be replaced in the field and all software		engine or whole router must be replaced in the field and all software
	which accesses the router must be updated with the new keys. Also,		which accesses the router must be updated with the new keys. Also,
	any network based initial contact with a new routing engine requires		any network based initial contact with a new routing engine requires
	trust in the public key presented on first contact.		trust in the public key presented on first contact.
	To allow operators to quickly replace routers without requiring		To allow operators to quickly replace routers without requiring
	update and distribution of the corresponding public keys in the RPKI,		update and distribution of the corresponding public keys in the RPKI,
	routers SHOULD allow the private BGPsec key to inserted via a		routers SHOULD allow the private BGPsec key to be inserted via a
	protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This		protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This
	lets the operator escrow the old private key via the mechanism used		lets the operator escrow the old private key via the mechanism used
	for operator-generated keys, see Section 5.2, such that it can be re-		for operator-generated keys, see Section 5.2, such that it can be re-
	inserted into a replacement router. The router MAY allow the private		inserted into a replacement router. The router MAY allow the private
	key to be to be off-loaded via the protected channel, but this SHOULD		key to be to be off-loaded via the protected channel, but this SHOULD
	be paired with functionality that sets the key into a permanent non-		be paired with functionality that sets the key into a permanent non-
	exportable state to ensure that it is not off-loaded at a future time		exportable state to ensure that it is not off-loaded at a future time
	by unauthorized operations.		by unauthorized operations.
	10. Security Considerations		10. Security Considerations
	skipping to change at page 10, line 50 ¶		skipping to change at page 11, line 4 ¶
	protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This		protected channel, e.g., SSH, NetConf (see [RFC6470]), SNMP. This
	lets the operator escrow the old private key via the mechanism used		lets the operator escrow the old private key via the mechanism used
	for operator-generated keys, see Section 5.2, such that it can be re-		for operator-generated keys, see Section 5.2, such that it can be re-
	inserted into a replacement router. The router MAY allow the private		inserted into a replacement router. The router MAY allow the private
	key to be to be off-loaded via the protected channel, but this SHOULD		key to be to be off-loaded via the protected channel, but this SHOULD
	be paired with functionality that sets the key into a permanent non-		be paired with functionality that sets the key into a permanent non-
	exportable state to ensure that it is not off-loaded at a future time		exportable state to ensure that it is not off-loaded at a future time
	by unauthorized operations.		by unauthorized operations.
	10. Security Considerations		10. Security Considerations
	The router's manual will describe whether the router supports one,		The router's manual will describe whether the router supports one,
	the other, or both of the key generation options discussed in the		the other, or both of the key generation options discussed in the
	earlier sections of this draft as well as other important security-		earlier sections of this draft as well as other important security-
	related information (e.g., how to SSH to the router). After		related information (e.g., how to SSH to the router). After
	familiarizing one's self with the capabilities of the router, an		familiarizing one's self with the capabilities of the router, an
	operator is encouraged to ensure that the router is patched with the		operator is encouraged to ensure that the router is patched with the
	latest software updates available from the manufacturer.		latest software updates available from the manufacturer.
	This document defines no protocols so in some sense introduces no new		This document defines no protocols. So, in some sense, it introduces
	security considerations. However, it relies on many others and the		no new security considerations. However, it relies on many others
	security considerations in the referenced documents should be		and the security considerations in the referenced documents should be
	consulted; notably, those document listed in Section 1 should be		consulted; notably, those document listed in Section 1 should be
	consulted first. PKI-relying protocols, of which BGPsec is one, have		consulted first. PKI-relying protocols, of which BGPsec is one, have
	many issues to consider so many in fact entire books have been		many issues to consider - so many, in fact, entire books have been
	written to address them; so listing all PKI-related security		written to address them; so listing all PKI-related security
	considerations is neither useful nor helpful; regardless, some boot-		considerations is neither useful nor helpful. Regardless, some boot-
	strapping-related issues are listed here that are worth repeating:		strapping-related issues are listed here that are worth repeating:
	Public-Private key pair generation: Mistakes here are for all		Public-Private key pair generation: Mistakes here are, for all,
	practical purposes catastrophic because PKIs rely on the pairing		practical purposes catastrophic because PKIs rely on the pairing
	of a difficult to generate public-private key pair with a signer;		of a difficult to generate public-private key pair with a signer;
	all key pairs MUST be generated from a good source of non-		all key pairs MUST be generated from a good source of non-
	deterministic random input [RFC4086].		deterministic random input [RFC4086].
	Private key protection at rest: Mistakes here are for all practical		Private key protection at rest: Mistakes here are, for all, practical
	purposes catastrophic because disclosure of the private key allows		purposes catastrophic because disclosure of the private key allows
	another entity to masquerade as (i.e., impersonate) the signer;		another entity to masquerade as (i.e., impersonate) the signer;
	all private keys MUST be protected when at rest in a secure		all private keys MUST be protected when at rest in a secure
	fashion. Obviously, how each router protects private keys is		fashion. Obviously, how each router protects private keys is
	implementation specific. Likewise, the local storage format for		implementation specific. Likewise, the local storage format for
	the private key is just that, a local matter.		the private key is just that, a local matter.
	Private key protection in transit: Mistakes here are for all		Private key protection in transit: Mistakes here are, for all,
	practical purposes catastrophic because disclosure of the private		practical purposes catastrophic because disclosure of the private
	key allows another entity to masquerade as (i.e., impersonate) the		key allows another entity to masquerade as (i.e., impersonate) the
	signer; transport security is therefore strongly RECOMMENDED. The		signer; transport security is therefore strongly RECOMMENDED. The
	level of security provided by the transport layer's security		level of security provided by the transport layer's security
	mechanism SHOULD be commensurate with the strength of the BGPsec		mechanism SHOULD be commensurate with the strength of the BGPsec
	key; there's no point in spending time and energy to generate an		key; there's no point in spending time and energy to generate an
	excellent public-private key pair and then transmit the private		excellent public-private key pair and then transmit the private
	key in the clear or with a known-to-be-broken algorithm, as it		key in the clear or with a known-to-be-broken algorithm, as it
	just undermines trust that the private key has been kept private.		just undermines trust that the private key has been kept private.
	Additionally, operators SHOULD ensure the transport security		Additionally, operators SHOULD ensure the transport security
End of changes. 27 change blocks.
	51 lines changed or deleted		51 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/