< draft-ietf-pki4ipsec-ikecert-profile-06.txt   draft-ietf-pki4ipsec-ikecert-profile-07.txt >
pki4ipsec B. Korver pki4ipsec B. Korver
Internet-Draft Network Resonance, Inc. Internet-Draft Network Resonance, Inc.
Expires: April 25, 2006 October 26, 2005 Expires: May 16, 2006 November 12, 2005
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-06
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.
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 April 25, 2006. This Internet-Draft will expire on May 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
4.1.2. SubjectName . . . . . . . . . . . . . . . . . . . . . 25 4.1.2. SubjectName . . . . . . . . . . . . . . . . . . . . . 25
4.1.3. X.509 Certificate Extensions . . . . . . . . . . . . . 26 4.1.3. X.509 Certificate Extensions . . . . . . . . . . . . . 26
4.2. X.509 Certificate Revocation Lists . . . . . . . . . . . . 32 4.2. X.509 Certificate Revocation Lists . . . . . . . . . . . . 32
4.2.1. Multiple Sources of Certificate Revocation 4.2.1. Multiple Sources of Certificate Revocation
Information . . . . . . . . . . . . . . . . . . . . . 32 Information . . . . . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . . . 34 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
7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 35 7. Intellectual Property Rights . . . . . . . . . . . . . . . . . 35
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.1. Normative References . . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . . 36
9.2. Informative References . . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . . 36
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 36 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 37
Appendix B. The Possible Dangers of Delta CRLs . . . . . . . . . 43 Appendix B. The Possible Dangers of Delta CRLs . . . . . . . . . 44
Appendix C. More on Empty CERTREQs . . . . . . . . . . . . . . . 44 Appendix C. More on Empty CERTREQs . . . . . . . . . . . . . . . 45
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 46 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 47
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 48 Intellectual Property and Copyright Statements . . . . . . . . . . 49
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 6, line 20 skipping to change at page 6, line 20
The following table summarizes the binding of the Identification The following table summarizes the binding of the Identification
Payload to the contents of end-entity certificates and of identity Payload to the contents of end-entity certificates and of identity
information to policy. Each ID type is covered more thoroughly in information to policy. Each ID type is covered more thoroughly in
the following sections. the following sections.
ID type | Support | Correspond | Cert | SPD lookup ID type | Support | Correspond | Cert | SPD lookup
| for send | PKIX Attrib | matching | rules | for send | PKIX Attrib | matching | rules
------------------------------------------------------------------- -------------------------------------------------------------------
| | | | | | | |
IP*_ADDR | MUST [1] | SubjAltName | MUST [2] | [3], [4] IP*_ADDR | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | iPAddress | | | | iPAddress | |
| | | | | | | |
FQDN | MUST [1] | SubjAltName | MUST [2] | [3], [4] FQDN | MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | dNSName | | | | dNSName | |
| | | | | | | |
USER_FQDN| MUST [1] | SubjAltName | MUST [2] | [3], [4] USER_FQDN| MUST [a] | SubjAltName | MUST [b] | [c], [d]
| | rfc822Name | | | | rfc822Name | |
| | | | | | | |
DN | MUST [1] | Entire | MUST [2] | MUST support lookup DN | MUST [a] | Entire | MUST [b] | MUST support lookup
| | Subject, | | on any combination | | Subject, | | on any combination
| | bitwise | | of C, CN, O, or OU | | bitwise | | of C, CN, O, or OU
| | compare | | | | compare | |
| | | | | | | |
IP range | MUST NOT | n/a | n/a | n/a IP range | MUST NOT | n/a | n/a | n/a
| | | | | | | |
| | | | | | | |
KEY_ID | MUST NOT | n/a | n/a | n/a KEY_ID | MUST NOT | n/a | n/a | n/a
| | | | | | | |
[1] = Implementation MUST have the configuration option to send this [a] = Implementation MUST have the configuration option to send this
ID type in the ID payload. Whether or not the ID type is used is a ID type in the ID payload. Whether or not the ID type is used is a
matter of local configuration. matter of local configuration.
[2] = The ID in the ID payload MUST match the contents of the [b] = The ID in the ID payload MUST match the contents of the
corresponding field (listed) in the certificate exactly, with no corresponding field (listed) in the certificate exactly, with no
other lookup. The matched ID MAY be used for SPD lookup, but is not other lookup. The matched ID MAY be used for SPD lookup, but is not
required to be used for this. See 2401bis [10], section 4.4.3.2 for required to be used for this. See 2401bis [10], section 4.4.3.2 for
more details. more details.
[3] = At a minimum, Implementation MUST be capable of being [c] = At a minimum, Implementation MUST be capable of being
configured to perform exact matching of the ID payload contents to an configured to perform exact matching of the ID payload contents to an
entry in the local SPD. entry in the local SPD.
[4] = In addition, the implementation MAY also be configurable to [d] = In addition, the implementation MAY also be configurable to
perform substring or wildcard matches of ID payload contents to perform substring or wildcard matches of ID payload contents to
entries in the local SPD. (More on this in Section 3.1.5). entries in the local SPD. (More on this in Section 3.1.5).
When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN, When sending an IPV4_ADDR, IPV6_ADDR, FQDN, or USER_FQDN,
implementations MUST be able to be configured to send the same string implementations MUST be able to be configured to send the same string
as appears in the corresponding SubjectAltName attribute. This as appears in the corresponding SubjectAltName attribute. This
document RECOMMENDS that deployers use this configuration option. document RECOMMENDS that deployers use this configuration option.
All these ID types are treated the same: as strings that can be All these ID types are treated the same: as strings that can be
compared easily and quickly to a corresponding string in an explicit compared easily and quickly to a corresponding string in an explicit
attribute in the certificate. Of these types, FQDN and USER_FQDN are attribute in the certificate. Of these types, FQDN and USER_FQDN are
skipping to change at page 14, line 41 skipping to change at page 14, line 41
o Kerberos Tokens o Kerberos Tokens
o SPKI Certificate o SPKI Certificate
o X.509 Certificate Attribute o X.509 Certificate Attribute
o IKEv2's Raw RSA Key o IKEv2's Raw RSA Key
o IKEv2's Hash and URL of X.509 bundle o IKEv2's Hash and URL of X.509 bundle
are out of the scope of this document. are out of the scope of this document.
3.2.2. X.509 Certificate - Signature 3.2.2. X.509 Certificate - Signature
This type requests that the end-entity certificate be a signing This type requests that the end-entity certificate be a certificate
certificate. used for signing.
3.2.3. Revocation Lists (CRL and ARL) 3.2.3. Revocation Lists (CRL and ARL)
ISAKMP and IKEv2 do not support Certificate Payload sizes over ISAKMP and IKEv2 do not support Certificate Payload sizes over
approximately 64K, which is too small for many CRLs. Therefore, the approximately 64K, which is too small for many CRLs. Therefore, the
acquisition of revocation material is to be dealt with out-of-band of acquisition of revocation material is to be dealt with out-of-band of
IKE. For this and other reasons, implementations SHOULD NOT generate IKE. For this and other reasons, implementations SHOULD NOT generate
CERTREQs where the Certificate Type is "Certificate Revocation List CERTREQs where the Certificate Type is "Certificate Revocation List
(CRL)" or "Authority Revocation List (ARL)". Implementations that do (CRL)" or "Authority Revocation List (ARL)". Implementations that do
generate such CERTREQs MUST NOT require the recipient to respond with generate such CERTREQs MUST NOT require the recipient to respond with
skipping to change at page 25, line 13 skipping to change at page 25, line 13
Implementations SHOULD include this payload whenever the public Implementations SHOULD include this payload whenever the public
portion of the keypair has been placed in a certificate. portion of the keypair has been placed in a certificate.
4. Profile of PKIX 4. Profile of PKIX
Except where specifically stated in this document, implementations Except where specifically stated in this document, implementations
MUST conform to the requirements of PKIX [5]. MUST conform to the requirements of PKIX [5].
4.1. X.509 Certificates 4.1. X.509 Certificates
Users deploying IKE and IPsec with certificates have often had little
control over the capabilities of CAs available to them.
Implementations of this specification may include configuration knobs
to disable checks required by this specification in order to permit
use with inflexible and/or noncompliant CAs. However, all checks on
certificates exist for a specific reason involving the security of
the entire system. Therefore, all checks MUST be enabled by default.
Administrators and users ought to understand the security purpose for
the various checks, and be clear on what security will be lost by
disabling the check.
4.1.1. Versions 4.1.1. Versions
Although PKIX states that "implementations SHOULD be prepared to Although PKIX states that "implementations SHOULD be prepared to
accept any version certificate", in practice this profile requires accept any version certificate", in practice this profile requires
certain extensions that necessitate the use of Version 3 certificates certain extensions that necessitate the use of Version 3 certificates
for all but self-signed certificates used as trust anchors. for all but self-signed certificates used as trust anchors.
Implementations that conform to this document MAY therefore reject Implementations that conform to this document MAY therefore reject
Version 1 and Version 2 certificates in all other cases. Version 1 and Version 2 certificates in all other cases.
4.1.2. SubjectName 4.1.2. SubjectName
skipping to change at page 27, line 21 skipping to change at page 27, line 27
apply in this situation. apply in this situation.
Since we are talking about using the public key to validate a Since we are talking about using the public key to validate a
signature, if the KeyUsage extension is present, then at least one of signature, if the KeyUsage extension is present, then at least one of
the digitalSignature or the nonRepudiation bits in the KeyUsage the digitalSignature or the nonRepudiation bits in the KeyUsage
extension MUST be set (both can be set as well). It is also fine if extension MUST be set (both can be set as well). It is also fine if
other KeyUsage bits are set. other KeyUsage bits are set.
A summary of the logic flow for peer cert validation follows: A summary of the logic flow for peer cert validation follows:
o If told (by configuration) to ignore KeyUsage (KU), accept cert o If no KU extension, continue.
regardless of its markings.
o If no KU extension, accept cert.
o If KU present and doesn't mention digitalSignature or o If KU present and doesn't mention digitalSignature or
nonRepudiation (both, in addition to other KUs, is also fine), nonRepudiation (both, in addition to other KUs, is also fine),
reject cert. reject cert.
o If none of the above, accept cert. o If none of the above, continue.
4.1.3.3. PrivateKeyUsagePeriod 4.1.3.3. PrivateKeyUsagePeriod
PKIX recommends against the use of this extension. The PKIX recommends against the use of this extension. The
PrivateKeyUsageExtension is intended to be used when signatures will PrivateKeyUsageExtension is intended to be used when signatures will
need to be verified long past the time when signatures using the need to be verified long past the time when signatures using the
private keypair may be generated. Since IKE SAs are short-lived private keypair may be generated. Since IKE SAs are short-lived
relative to the intended use of this extension in addition to the relative to the intended use of this extension in addition to the
fact that each signature is validated only a single time, the fact that each signature is validated only a single time, the
usefulness of this extension in the context of IKE is unclear. usefulness of this extension in the context of IKE is unclear.
skipping to change at page 30, line 14 skipping to change at page 30, line 19
values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp- values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-
ipsecUser.) ipsecUser.)
The CA SHOULD NOT mark the EKU extension in certificates for use with The CA SHOULD NOT mark the EKU extension in certificates for use with
IKE and one or more other applications. Nevertheless, this document IKE and one or more other applications. Nevertheless, this document
defines an ExtendedKeyUsage keyPurposeID that MAY be used to limit a defines an ExtendedKeyUsage keyPurposeID that MAY be used to limit a
certificate's use: certificate's use:
id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 } id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
where id-kp is defined in RFC-3280 [5]. If the CA administrator where id-kp is defined in RFC-3280 [5]. If a certificate is intended
feels they must use an EKU for some other application, then such to be used with both IKE and other applications, and one of the other
certificates MUST contain either the keyPurposeID id-kp-ipsecIKE or applications requires use of an EKU value, then such certificates
MUST contain either the keyPurposeID id-kp-ipsecIKE or
anyExtendedKeyUsage [5] as well as the keyPurposeID values associated anyExtendedKeyUsage [5] as well as the keyPurposeID values associated
with the other applications for which the certificate is intended to with the other applications. Similarly, if a CA issues multiple
be used. Recall however, EKU extensions in certificates meant for otherwise-similar certificates for multiple applications including
use in IKE are NOT RECOMMENDED. IKE, and it is intended that the IKE certificate NOT be used with
another application, the IKE certificate MAY contain an EKU extension
listing a keyPurposeID of id-kp-ipsecIKE to discourage its use with
the other application. Recall however, EKU extensions in
certificates meant for use in IKE are NOT RECOMMENDED.
A summary of the logic flow for peer certificate validation regarding A summary of the logic flow for peer certificate validation regarding
the EKU extension follows: the EKU extension follows:
o If told (by configuration) to ignore ExtendedKeyUsage (EKU), o If no EKU extension, continue.
accept cert regardless of the presence or absence of the
extension.
o If no EKU extension, accept cert.
o If EKU present AND contains either id-kp-ipsecIKE or o If EKU present AND contains either id-kp-ipsecIKE or
anyExtendedKeyUsage, accept cert. anyExtendedKeyUsage, continue.
o Otherwise, reject cert. o Otherwise, reject cert.
4.1.3.13. CRLDistributionPoints 4.1.3.13. CRLDistributionPoints
Because this document deprecates the sending of CRLs in-band, the use Because this document deprecates the sending of CRLs in-band, the use
of CRLDistributionPoints (CDP) becomes very important if CRLs are of CRLDistributionPoints (CDP) becomes very important if CRLs are
used for revocation checking (as opposed to say Online Certificate used for revocation checking (as opposed to say Online Certificate
Status Protocol - OCSP [15]). The IPsec peer either needs to have a Status Protocol - OCSP [15]). The IPsec peer either needs to have a
URL for a CRL written into its local configuration, or it needs to URL for a CRL written into its local configuration, or it needs to
learn it from CDP. Therefore, Certification Authority learn it from CDP. Therefore, Certification Authority
skipping to change at page 31, line 45 skipping to change at page 32, line 7
document deprecates the sending of CRLs in band, the use of document deprecates the sending of CRLs in band, the use of
AuthorityInfoAccess (AIA) becomes very important if OCSP [15] is to AuthorityInfoAccess (AIA) becomes very important if OCSP [15] is to
be used for revocation checking (as opposed to CRLs). The IPsec peer be used for revocation checking (as opposed to CRLs). The IPsec peer
either needs to have a URI for the OCSP query written into its local either needs to have a URI for the OCSP query written into its local
configuration, or it needs to learn it from AIA. Therefore, configuration, or it needs to learn it from AIA. Therefore,
implementations SHOULD support this extension, especially if OCSP implementations SHOULD support this extension, especially if OCSP
will be used. will be used.
4.1.3.17. SubjectInfoAccess 4.1.3.17. SubjectInfoAccess
PKIX defines the SubjectInfoAccess private certificate extension, PKIX defines the SubjectInfoAccess certificate extension, which is
which is used to indicate "how to access information and services for used to indicate "how to access information and services for the
the subject of the certificate in which the extension appears." This subject of the certificate in which the extension appears." This
extension has no known use in the context of IPsec. Conformant IKE extension has no known use in the context of IPsec. Conformant IKE
implementations SHOULD ignore this extension when present. implementations SHOULD ignore this extension when present.
4.2. X.509 Certificate Revocation Lists 4.2. X.509 Certificate Revocation Lists
When validating certificates, IKE implementations MUST make use of When validating certificates, IKE implementations MUST make use of
certificate revocation information, and SHOULD support such certificate revocation information, and SHOULD support such
revocation information in the form of CRLs, unless non-CRL revocation revocation information in the form of CRLs, unless non-CRL revocation
information is known to be the only method for transmitting this information is known to be the only method for transmitting this
information. Deployments that intend to use CRLs for revocation information. Deployments that intend to use CRLs for revocation
skipping to change at page 33, line 29 skipping to change at page 33, line 35
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 authors 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 exposes a larger window of other hand, failure to issue delta CRLs may expose a larger window of
vulnerability. See the Security Considerations section of PKIX [5] vulnerability if a full CRL is not issued as often as delta CRLs
for additional discussion. Implementors as well as administrators would be. See the Security Considerations section of PKIX [5] for
are encouraged to consider these issues. additional discussion. Implementors as well as administrators are
encouraged to consider these issues.
4.2.2.5. IssuingDistributionPoint 4.2.2.5. IssuingDistributionPoint
A CA that is using CRLDistributionPoints may do so to provide many A CA that is using CRLDistributionPoints may do so to provide many
"small" CRLs, each only valid for a particular set of certificates "small" CRLs, each only valid for a particular set of certificates
issued by that CA. To associate a CRL with a certificate, the CA issued by that CA. To associate a CRL with a certificate, the CA
places the CRLDistributionPoints extension in the certificate, and places the CRLDistributionPoints extension in the certificate, and
places the IssuingDistributionPoint in the CRL. The places the IssuingDistributionPoint in the CRL. The
distributionPointName field in the CRLDistributionPoints extension distributionPointName field in the CRLDistributionPoints extension
MUST be identical to the distributionPoint field in the MUST be identical to the distributionPoint field in the
skipping to change at page 35, line 24 skipping to change at page 35, line 32
6.2. IKEv1 Main Mode 6.2. IKEv1 Main Mode
Certificates may be included in any message, and therefore Certificates may be included in any message, and therefore
implementations may wish to respond with CERTs in a message that implementations may wish to respond with CERTs in a message that
offers privacy protection, in Main Mode messages 5 and 6. offers privacy protection, in Main Mode messages 5 and 6.
Implementations may not wish to respond with CERTs in the second Implementations may not wish to respond with CERTs in the second
message, thereby violating the identity protection feature of Main message, thereby violating the identity protection feature of Main
Mode in IKEv1. Mode in IKEv1.
6.3. Disabling Certificate Checks
It is important to note that anywhere this document suggests
implementors provide users with the configuration option to simplify,
modify, or disable a feature or verification step, there may be
security consequences for doing so. Deployment experience has shown
that such flexibility may be required in some environments, but
making use of such flexibility can be inappropriate in others. Such
configuration options MUST default to "enabled" and it is appropriate
to provide warnings to users when disabling such features.
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 4 skipping to change at page 37, line 18
[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] 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
October 2005 (-06)
November 2005 (-07)
* 3.1 - renumbered table notes to avoid confusion with references
(9 Nov 2005 pki4ipsec email from Jim Schaad)
* 3.2.2 - changed "signing certificate" to "a certificate used
for signing" (9 Nov 2005 pki4ipsec email from Jim Schaad)
* 4.1 - added text re: implications of disabling checks ("escape
clause") (8 Nov 2005 pki4ipsec email from Bill Sommerfeld, 10
Nov 2005 pki4ipsec email from Gregory M Lebovitz)
* 4.1.3.2 - removed text from pseudocode: "If told (by
configuration) to ignore KeyUsage (KU), accept cert regardless
of its markings."
* 4.1.3.12 - replaced text with clearer text (8 Nov 2005
pki4ipsec email from Bill Sommerfeld)
* 4.1.3.12 - removed text from pseudocode: "If told (by
configuration) to ignore ExtendedKeyUsage (EKU), accept cert
regardless of the presence or absence of the extension."
* 4.1.3.17 - removed gratuitous "private" modifier from
SubjectInfoAccess section (9 Nov 2005 pki4ipsec email from Jim
Schaad)
* 4.2.2.4.2 - clarified delta CRL text so that it no longer could
be read as implying that full CRLs can't be issued at the time
a certificate is revoked. (9 Nov 2005 pki4ipsec email from Jim
Schaad)
* Security Considerations - added "Disabling Certificate Checks"
section
October 2005 (-06)
* 4.1.3.12 - added text re: id-kp-ipsecIKE * 4.1.3.12 - added text re: id-kp-ipsecIKE
July 2005 (-05) July 2005 (-05)
* 3.1 - added "See 2401bis [10], section 4.4.3.2 for more * 3.1 - added "See 2401bis [10], section 4.4.3.2 for more
details." to resolve issue #561. details." to resolve issue #561.
* 3.1.10 - added text pointing to PAD in 2401bis [10] to * 3.1.10 - added text pointing to PAD in 2401bis [10] to
discussion of binding identity to policy. discussion of binding identity to policy.
December 2004 (-04) December 2004 (-04)
 End of changes. 27 change blocks. 
44 lines changed or deleted 95 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/