< draft-ietf-pki4ipsec-ikecert-profile-07.txt		draft-ietf-pki4ipsec-ikecert-profile-08.txt >
	pki4ipsec B. Korver		pki4ipsec B. Korver
	Internet-Draft Network Resonance, Inc.		Internet-Draft Network Resonance, Inc.
	Expires: May 16, 2006 November 12, 2005		Expires: August 19, 2006 February 15, 2006
	The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX		The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
	draft-ietf-pki4ipsec-ikecert-profile-06		draft-ietf-pki4ipsec-ikecert-profile-08
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 16, 2006.		This Internet-Draft will expire on August 19, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	IKE and PKIX both provide frameworks that must be profiled for use in		IKE and PKIX both provide frameworks that must be profiled for use in
	a given application. This document provides a profile of IKE and		a given application. This document provides a profile of IKE and
	PKIX that defines the requirements for using PKI technology in the		PKIX that defines the requirements for using PKI technology in the
	context of IKE/IPsec. The document complements protocol		context of IKE/IPsec. The document complements protocol
	specifications such as IKEv1 and IKEv2, which assume the existence of		specifications such as IKEv1 and IKEv2, which assume the existence of
	public key certificates and related keying materials, but which do		public key certificates and related keying materials, but which do
	not address PKI issues explicitly. This document addresses those		not address PKI issues explicitly. This document addresses those
	skipping to change at page 3, line 16 ¶		skipping to change at page 3, line 16 ¶
	4.2.2. X.509 Certificate Revocation List Extensions . . . . . 32		4.2.2. X.509 Certificate Revocation List Extensions . . . . . 32
	5. Configuration Data Exchange Conventions . . . . . . . . . . . 34		5. Configuration Data Exchange Conventions . . . . . . . . . . . 34
	5.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 34		5.1. Certificates . . . . . . . . . . . . . . . . . . . . . . . 34
	5.2. CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 34		5.2. CRLs and ARLs . . . . . . . . . . . . . . . . . . . . . . 34
	5.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 34		5.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 34
	5.4. PKCS#10 Certificate Signing Requests . . . . . . . . . . . 35		5.4. PKCS#10 Certificate Signing Requests . . . . . . . . . . . 35
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 35		6. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	6.1. Certificate Request Payload . . . . . . . . . . . . . . . 35		6.1. Certificate Request Payload . . . . . . . . . . . . . . . 35
	6.2. IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 35		6.2. IKEv1 Main Mode . . . . . . . . . . . . . . . . . . . . . 35
	6.3. Disabling Certificate Checks . . . . . . . . . . . . . . . 35		6.3. Disabling Certificate Checks . . . . . . . . . . . . . . . 35
	7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 35		6.4. Strength of Signature Hashing Algorithms . . . . . . . . . 35
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 36
			8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 36		9.1. Normative References . . . . . . . . . . . . . . . . . . . 36
	9.2. Informative References . . . . . . . . . . . . . . . . . . 36		9.2. Informative References . . . . . . . . . . . . . . . . . . 37
	Appendix A. Change History . . . . . . . . . . . . . . . . . . . 37		Appendix A. Change History . . . . . . . . . . . . . . . . . . . 38
	Appendix B. The Possible Dangers of Delta CRLs . . . . . . . . . 44		Appendix B. The Possible Dangers of Delta CRLs . . . . . . . . . 45
	Appendix C. More on Empty CERTREQs . . . . . . . . . . . . . . . 45		Appendix C. More on Empty CERTREQs . . . . . . . . . . . . . . . 46
	Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 47		Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 48
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49
	Intellectual Property and Copyright Statements . . . . . . . . . . 49		Intellectual Property and Copyright Statements . . . . . . . . . . 50
	1. Introduction		1. Introduction
	IKE [1], ISAKMP [2] and IKEv2 [3] provide a secure key exchange		IKE [1], ISAKMP [2] and IKEv2 [3] provide a secure key exchange
	mechanism for use with IPsec [4]. In many cases the peers		mechanism for use with IPsec [4]. In many cases the peers
	authenticate using digital certificates as specified in PKIX [5].		authenticate using digital certificates as specified in PKIX [5].
	Unfortunately, the combination of these standards leads to an		Unfortunately, the combination of these standards leads to an
	underspecified set of requirements for the use of certificates in the		underspecified set of requirements for the use of certificates in the
	context of IPsec.		context of IPsec.
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 23 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [7].		document are to be interpreted as described in RFC-2119 [7].
	3. Profile of IKEv1/ISAKMP and IKEv2		3. Profile of IKEv1/ISAKMP and IKEv2
	3.1. Identification Payload		3.1. Identification Payload
	The Identification (ID) Payload is used to indicate the identity that		The Identification (ID) Payload is used to indicate the identity that
	the sender claims to be speaking for. The recipient can then use the		the sender claims to be speaking for. The recipient can then use the
	ID as a lookup key for policy and whatever certificate store or		ID as a lookup key for policy and for certificate lookup in whatever
	directory that it has available. Our primary concern in this section		certificate store or directory that it has available. Our primary
	is to profile the ID payload so that it can be safely used to		concern in this section is to profile the ID payload so that it can
	generate or lookup policy. IKE mandates the use of the ID payload in		be safely used to generate or lookup policy. IKE mandates the use of
	Phase 1.		the ID payload in Phase 1.
	The DOI [6] defines the 11 types of Identification Data that can be		The DOI [6] defines the 11 types of Identification Data that can be
	used and specifies the syntax for these types. These are discussed		used and specifies the syntax for these types. These are discussed
	below in detail.		below in detail.
	The ID payload requirements in this document cover only the portion		The ID payload requirements in this document cover only the portion
	of the explicit policy checks that deal with the Identification		of the explicit policy checks that deal with the Identification
	Payload specifically. For instance, in the case where ID does not		Payload specifically. For instance, in the case where ID does not
	contain an IP address, checks such as verifying that the peer source		contain an IP address, checks such as verifying that the peer source
	address is permitted by the relevant policy are not addressed here as		address is permitted by the relevant policy are not addressed here as
	skipping to change at page 15, line 24 ¶		skipping to change at page 15, line 24 ¶
	relevant revocation material from a URL, for validation processing.		relevant revocation material from a URL, for validation processing.
	In addition, implementations MUST have the ability to configure		In addition, implementations MUST have the ability to configure
	validation checking information for each certification authority.		validation checking information for each certification authority.
	Regardless of the method (CDP, AIA, or static configuration), the		Regardless of the method (CDP, AIA, or static configuration), the
	acquisition of revocation material SHOULD occur out-of-band of IKE.		acquisition of revocation material SHOULD occur out-of-band of IKE.
	3.2.4. PKCS #7 wrapped X.509 certificate		3.2.4. PKCS #7 wrapped X.509 certificate
	This ID type defines a particular encoding (not a particular		This ID type defines a particular encoding (not a particular
	certificate type), some current implementations may ignore CERTREQs		certificate type), some current implementations may ignore CERTREQs
	they receive which contain this ID type, and the authors are unaware		they receive which contain this ID type, and the editors are unaware
	of any implementations that generate such CERTREQ messages.		of any implementations that generate such CERTREQ messages.
	Therefore, the use of this type is deprecated. Implementations		Therefore, the use of this type is deprecated. Implementations
	SHOULD NOT require CERTREQs that contain this Certificate Type.		SHOULD NOT require CERTREQs that contain this Certificate Type.
	Implementations which receive CERTREQs which contain this ID type MAY		Implementations which receive CERTREQs which contain this ID type MAY
	treat such payloads as synonymous with "X.509 Certificate -		treat such payloads as synonymous with "X.509 Certificate -
	Signature".		Signature".
	3.2.5. IKEv2's Hash and URL of X.509 certificate		3.2.5. IKEv2's Hash and URL of X.509 certificate
	This ID type defines a request for the peer to send a hash and URL of		This ID type defines a request for the peer to send a hash and URL of
	skipping to change at page 22, line 14 ¶		skipping to change at page 22, line 14 ¶
	type. Implementations SHOULD NOT generate CERTs that contain this		type. Implementations SHOULD NOT generate CERTs that contain this
	Certificate Type. Implementations SHOULD accept CERTs that contain		Certificate Type. Implementations SHOULD accept CERTs that contain
	this Certificate Type because several implementations are known to		this Certificate Type because several implementations are known to
	generate them. Note that those implementations sometimes include		generate them. Note that those implementations sometimes include
	entire certificate hierarchies inside a single CERT PKCS #7 payload,		entire certificate hierarchies inside a single CERT PKCS #7 payload,
	which violates the requirement specified in ISAKMP that this payload		which violates the requirement specified in ISAKMP that this payload
	contain a single certificate.		contain a single certificate.
	3.3.6. Location of Certificate Payloads		3.3.6. Location of Certificate Payloads
	In IKEv1, the CERT payload MUST be in messages 5 and 6. In IKEv2,		In IKEv1 Main Mode, the CERT payload MUST be in messages 5 and 6. In
	the CERT payload must be in messages 3 and 4. Note that in IKEv2, it		IKEv2, the CERT payload must be in messages 3 and 4. Note that in
	is possible to have one side authenticating with certificates while		IKEv2, it is possible to have one side authenticating with
	the other side authenticates with preshared keys.		certificates while the other side authenticates with preshared keys.
	3.3.7. Certificate Payloads Not Mandatory		3.3.7. Certificate Payloads Not Mandatory
	An implementation which does not receive any CERTREQs during an		An implementation which does not receive any CERTREQs during an
	exchange SHOULD NOT send any CERT payloads, except when explicitly		exchange SHOULD NOT send any CERT payloads, except when explicitly
	configured to proactively send CERT payloads in order to interoperate		configured to proactively send CERT payloads in order to interoperate
	with non-compliant implementations which fail to send CERTREQs even		with non-compliant implementations which fail to send CERTREQs even
	when certificates are desired. In this case, an implementation MAY		when certificates are desired. In this case, an implementation MAY
	send the certificate chain (not including the trust anchor)		send the certificate chain (not including the trust anchor)
	associated with the end-entity certificate. This MUST NOT be the		associated with the end-entity certificate. This MUST NOT be the
	skipping to change at page 33, line 31 ¶		skipping to change at page 33, line 31 ¶
	4.2.2.4.2. Delta CRL Recommendations		4.2.2.4.2. Delta CRL Recommendations
	Since some IKE implementations that do not support delta CRLs may		Since some IKE implementations that do not support delta CRLs may
	behave incorrectly or insecurely when presented with delta CRLs,		behave incorrectly or insecurely when presented with delta CRLs,
	administrators and deployers should consider whether issuing delta		administrators and deployers should consider whether issuing delta
	CRLs increases security before issuing such CRLs. And, if all the		CRLs increases security before issuing such CRLs. And, if all the
	elements in the VPN and PKI systems do not adequately support Delta		elements in the VPN and PKI systems do not adequately support Delta
	CRLs, then their use should be questioned.		CRLs, then their use should be questioned.
	The authors are aware of several implementations which behave in an		The editors are aware of several implementations which behave in an
	incorrect or insecure manner when presented with delta CRLs. See		incorrect or insecure manner when presented with delta CRLs. See
	Appendix B for a description of the issue. Therefore, this		Appendix B for a description of the issue. Therefore, this
	specification RECOMMENDS NOT issuing delta CRLs at this time. On the		specification RECOMMENDS NOT issuing delta CRLs at this time. On the
	other hand, failure to issue delta CRLs may expose a larger window of		other hand, failure to issue delta CRLs may expose a larger window of
	vulnerability if a full CRL is not issued as often as delta CRLs		vulnerability if a full CRL is not issued as often as delta CRLs
	would be. See the Security Considerations section of PKIX [5] for		would be. See the Security Considerations section of PKIX [5] for
	additional discussion. Implementors as well as administrators are		additional discussion. Implementors as well as administrators are
	encouraged to consider these issues.		encouraged to consider these issues.
	4.2.2.5. IssuingDistributionPoint		4.2.2.5. IssuingDistributionPoint
	skipping to change at page 35, line 43 ¶		skipping to change at page 35, line 43 ¶
	It is important to note that anywhere this document suggests		It is important to note that anywhere this document suggests
	implementors provide users with the configuration option to simplify,		implementors provide users with the configuration option to simplify,
	modify, or disable a feature or verification step, there may be		modify, or disable a feature or verification step, there may be
	security consequences for doing so. Deployment experience has shown		security consequences for doing so. Deployment experience has shown
	that such flexibility may be required in some environments, but		that such flexibility may be required in some environments, but
	making use of such flexibility can be inappropriate in others. Such		making use of such flexibility can be inappropriate in others. Such
	configuration options MUST default to "enabled" and it is appropriate		configuration options MUST default to "enabled" and it is appropriate
	to provide warnings to users when disabling such features.		to provide warnings to users when disabling such features.
			6.4. Strength of Signature Hashing Algorithms
			At the time that this document is being written, popular
			certification authorities and CA software issue certificates using
			the RSA-with-SHA1 and RSA-with-MD5 signature algorithms.
			Implementations MUST be able to validate certificates with either of
			those algorithms.
			As described in [16], both the MD5 and SHA-1 hash algorithms are
			weaker than originally expected with respect to hash collisions.
			Certificates that use these hash algorithms as part of their
			signature algorithms could conceivably be subject to an attack where
			a CA issues a certificate with a particular identity, and the
			recipient of that certificate can create a different valid
			certificate with a different identity. So far, such an attack is
			only theoretical, even with the weaknesses found in the hash
			algorithms.
			Because of the recent attacks, there has been a heightened interest
			in having widespread deployment of additional signature algorithms.
			The algorithm that has been mentioned most often is RSA-with-SHA256,
			two types of which are described in detail in [17]. It is widely
			expected that this signature algorithm will be much more resilient to
			collision-based attacks than the current RSA-with-SHA1 and RSA-with-
			MD5, although no proof of that has been shown. There is active
			discussion in the cryptographic community of better hash functions
			that could be used in signature algorithms.
			In order to interoperate, all implementations need to be able to
			validate signatures for all algorithms that the implementations will
			encounter. Therefore, implementations SHOULD be able to use
			signatures that use the sha256WithRSAEncryption signature algorithm
			(PKCS#1 version 1.5) as soon as possible. At the time that this
			document is being written, there are no common implementations that
			issue certificates with this algorithm, but it is expected that there
			will be significant deployment of this algorithm by the end of 2007.
	7. Intellectual Property Rights		7. Intellectual Property Rights
	No new intellectual property rights are introduced by this document.		No new intellectual property rights are introduced by this document.
	8. IANA Considerations		8. IANA Considerations
	There are no known numbers which IANA will need to manage.		There are no known numbers which IANA will need to manage.
	9. References		9. References
	skipping to change at page 37, line 13 ¶		skipping to change at page 37, line 51 ¶
	progress), September 2003.		progress), September 2003.
	[14] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-		[14] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-
	Domain Routing (CIDR): an Address Assignment and Aggregation		Domain Routing (CIDR): an Address Assignment and Aggregation
	Strategy", RFC 1519, September 1993.		Strategy", RFC 1519, September 1993.
	[15] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,		[15] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams,
	"X.509 Internet Public Key Infrastructure Online Certificate		"X.509 Internet Public Key Infrastructure Online Certificate
	Status Protocol - OCSP", RFC 2560, June 1999.		Status Protocol - OCSP", RFC 2560, June 1999.
	[16] Arsenault, A. and S. Turner, "Internet X.509 Public Key		[16] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes
			in Internet Protocols", RFC 4270, November 2005.
			[17] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
			and Identifiers for RSA Cryptography for use in the Internet
			X.509 Public Key Infrastructure Certificate and Certificate
			Revocation List (CRL) Profile", RFC 4055, June 2005.
			[18] Arsenault, A. and S. Turner, "Internet X.509 Public Key
	Infrastructure: Roadmap", draft-ietf-pkix-roadmap-09 (work in		Infrastructure: Roadmap", draft-ietf-pkix-roadmap-09 (work in
	progress), July 2002.		progress), July 2002.
	Appendix A. Change History		Appendix A. Change History
			February 2006 (-08)
			* 3.2.6 - clarified text, that it applies to Main Mode only
			* Added text to security considerations regarding SHA-256 (30 Jan
			2005 pki4ipsec email from Paul Hoffman)
	November 2005 (-07)		November 2005 (-07)
	* 3.1 - renumbered table notes to avoid confusion with references		* 3.1 - renumbered table notes to avoid confusion with references
	(9 Nov 2005 pki4ipsec email from Jim Schaad)		(9 Nov 2005 pki4ipsec email from Jim Schaad)
	* 3.2.2 - changed "signing certificate" to "a certificate used		* 3.2.2 - changed "signing certificate" to "a certificate used
	for signing" (9 Nov 2005 pki4ipsec email from Jim Schaad)		for signing" (9 Nov 2005 pki4ipsec email from Jim Schaad)
	* 4.1 - added text re: implications of disabling checks ("escape		* 4.1 - added text re: implications of disabling checks ("escape
	clause") (8 Nov 2005 pki4ipsec email from Bill Sommerfeld, 10		clause") (8 Nov 2005 pki4ipsec email from Bill Sommerfeld, 10
	Nov 2005 pki4ipsec email from Gregory M Lebovitz)		Nov 2005 pki4ipsec email from Gregory M Lebovitz)
	* 4.1.3.2 - removed text from pseudocode: "If told (by		* 4.1.3.2 - removed text from pseudocode: "If told (by
	skipping to change at page 48, line 13 ¶		skipping to change at page 49, line 13 ¶
	of coverting the text to XML format.		of coverting the text to XML format.
	Author's Address		Author's Address
	Brian Korver		Brian Korver
	Network Resonance, Inc.		Network Resonance, Inc.
	2483 E. Bayshore Rd.		2483 E. Bayshore Rd.
	Palo Alto, CA 94303		Palo Alto, CA 94303
	US		US
	Phone: +1 415 812 7700		Phone: +1 650 812 7705
	Email: briank@networkresonance.com		Email: briank@networkresonance.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	skipping to change at page 49, line 41 ¶		skipping to change at page 50, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 15 change blocks.
	27 lines changed or deleted		79 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/