Here are some comments on draft-ietf-ipsec-pki-profile-03.txt. I have divided them into Minor Corrections and More Significant Comments. I hope you won't be put off by the number of comments. This is a very valuable document and I want to make sure that it gets a careful review. I apologize for taking so long to get to it. Thanks, Steve Hanna --------- More Significant Comments * What are your plans for this document? There's clearly a need for the document. Do you plan to put it on the submit it as a standards track document? I guess so, since it includes lots of MUST and SHOULD language. This is probably a good idea, since IKEv1 and ISAKMP are too vague about PKI to achieve interoperability. * What about an IKEv2 version of this document? The current version cites and focusses on IKEv1 and ISAKMP. That's OK and probably most useful for today's products. But I expect that products based on IKEv2 will soon be shipping (if they're not already). You should probably prepare a revised version of this document that talks about how to use PKI with IKEv2. The content will be similar, so it shouldn't be hard to create. But proceeding without it may lead to the same sorts of PKI-related interoperability problems that arose with IKEv1. * I think you should say somewhere that, except where specifically stated in this document, IPSEC implementations MUST conform to the requirements of RFC 3280. Otherwise, people may play fast and loose and you're not likely to get interoperability. * In section 3.3.8.1, you say "Implementations MAY send other certificates from the chain." Actually, they MAY send other certificates as well (as you mention in section 3.4.10.5). I suggest that you change section 3.3.8.1 to simply say "Implementations MAY send other certificates." * In section 3.3.9.1 says: Upon receipt of a CERTREQ where the Certificate Type is "Certificate Revocation List (CRL)", implementations MUST respond by sending the CRL issued by the issuer of each certificate in the chain between the end entity certificate and the certificate whose Issuer Name matches the name specified in the Certificate Authority field. In additional, implementations MUST send any certificates that the peer will need to validate those CRLs, while optionally eliding those certificates and CRLs identified in CERTREQs as already being in the possession of the peer. This doesn't cover all the certs and CRLs that should be sent. You should also send any CRLs needed to validate the certificates needed to validate the first set of CRLs. And so on, and so on. I think it would be better to say: Upon receipt of a CERTREQ where the Certificate Type is "Certificate Revocation List (CRL)", implementations MUST respond by sending all the CRLs needed to verify the revocation status of the certificates sent. If additional certificates or CRLs are needed to verify the validity of these CRLs, they MUST be sent as well. * Russ Housley raised a good issue with section 3.3.9.1 in his email last fall. He pointed out that a Road Warrior probably may not have many of the CRLs needed to verify the revocation status of his certificates. And he may not be able to get these until after IPSEC is up and running. You could address this problem by saying something like this: If an implementation does not have and cannot obtain current versions of all these CRLs (as when it has not had network access in some time), it SHOULD send what it has. The recipient MAY use the CRLDistributionPoints extension to obtain the necessary CRLs. * In section 3.4.10.5, you describe one reason why implementations may send certificates that aren't relevant to an exchange. Another reason why an implementation may send certificates that seem to be irrelevant is that there may be two chains from the Certificate Authority to the end entity, each of which is only valid with certain validation parameters (like acceptable policies). Since the end entity doesn't know which parameters the relying party is using, it should send the certs needed for both chains (even if there's only one CERTREQ). This should probably be described in a new section between section 3.4.9 and 3.4.10, since it's a useful point and a bit tricky to understand. * In section 4.1.2.3, you talk about how implementations can place FQDNs in the Subject Name field using the domainComponent attribute type. I know that a lot of people use this attribute type for organizing their X.500 namespace, but this is the first time I ever heard it suggested that a program should concatenate the DC attributes to make a DNS name and then use that for authentication. Is there already software out there that does this? If not, why suggest it? Why not just tell people to use dNSName? * In section 4.1.3, you say that implementations MUST recognize the KeyUsage, SubjectAltName, and BasicConstraints extensions. RFC 3280 also requires support for several other extensions: CertificatePolicies, NameConstraints, PolicyConstraints, ExtendedKeyUsage, and InhibitAnyPolicy. Is there any good reason not to require support for those policies here? I'd be glad to explain why they're useful in many PKIs. The main argument I can see is that lots of existing software doesn't support those extensions. Given that, I'd be glad to see a few sentences saying that most software doesn't support them today but that software SHOULD start to support them because customers are starting to use them (big customers like the U.S. Government). * Likewise, in sections 4.1.3.5, 4.1.3.11, and 4.1.3.12 it would be good to say something similar (mentioning that support for these extensions is required by RFC 3280, but not widespread; therefore, implementations SHOULD support them but not use them for now). * Section 4.1.3.9 says that implementations MAY ignore the SubjectDirectoryAttributes extension. But according to the chart in section 4.1.3, implementations MUST reject a certificate if it contains a critical SubjectDirectoryAttributes extension, even though PKIX says it MUST NOT be critical. That's the correct behavior. If you see a critical extension you don't recognize, you MUST reject the cert. * Section 4.1.3.13 says that a certificate that contains a critical ExtendedKeyUsage extension can't be used for IPSEC. That ignores the anyExtendedKeyUsage keyPurposeID (which is describe in section 4.2.1.13 of RFC 3280). If the EKU extension includes that OID, then the cert can be used for any purpose. I'd also just like to say that it's a bit of a bummer to not have an EKU OID for IPSEC. That means that it's not possible to make a certificate that can only be used for IPSEC. If you allow the certificate to be used for IPSEC, you must also allow it to be used for S/MIME, TLS/SSL, and any other purpose. Of course, you can restrict its use by having a separate PKI that's used only for IPSEC (or maybe a separate certificate policy for IPSEC), but those solutions are awfully painful. I understand that people were not happy with the EKU OIDs defined earlier, but could someone explain the reason for not having some sort of IPSEC EKU OID? I read the earlier email traffic and didn't quite get it. Thanks. * In section 4.1.3.17, it's stated that the AIA extension "has no known use in the context of IPsec". What about using it to provide the location of an OCSP responder with information about the certificate? Support for OCSP is certainly not required, but it's pretty common and useful. I think you should talk about this and say that implementations MAY support it. I don't think you should make a recommendation or requirement. * Section 5 requires support for a particular format for exchanging configuration data. What are these certificates and public keys intended to be used for? Trust anchors? Just a cache of certificates? Certificates received from a CA in response to a certificate signing request? I think there should be some explanation. * Section 6.2.3.1 says that "an implementation MAY interpret the nonRepudiation bit as synonymous with the keyEncipherment". I don't think that's right. * Appendix B describes a VERY BAD algorithm for certificate status checking. This algorithm assumes the certificate is valid unless proven otherwise. A proper algorithm assumes the opposite (revoked unless proven otherwise). Please put some STRONG warnings that this algorithm is completely broken and tell people to use the algorithm in RFC 3280 section 6.3 instead. The algorithm described in Appendix B is broken in so many ways other than delta CRLs. If I provide a CRL whose signature doesn't match or one that "doesn't decode", my cert will be considered not revoked. That's just broken. You might as well not check revocation. Minor Corrections * In the abstract, "compliments" should be "complements". * In the Introduction, "threst" should be "the rest". * In section 3.2.5, "DN that MUST be used" should be "DN MUST be used". * In section 3.2.6, "with the a GeneralName" should be "with a GeneralName". * In section 3.2.7, "Type ID_KEY_ID type used" should be "The ID_KEY_ID type is used". * In section 3.2.11, "wores" should be "words". * In section 3.3.8.1, instead of saying "implementations MUST respond by sending each certificate in the chain from the end entity certificate to the certificate whose Issuer Name matches the name specified in the Certificate Authority field", it would be clearer to say "... from the end entity certificate up to and including to the certificate ...". * In section 3.3.10.2, "as if there were empty" should be "as if they were empty". * At the end of section 3.3.11.3, I think it would be clearer to say "the fact that TA is a trust anchor" instead of just "that TA is a trust anchor". * In section 3.4.1, the phrase "if CRLs are desired" seems to have been copied from section 3.3.1. For this section, I think it should be reworded to say "if CRLs are being sent". * In section 3.4.5, change "an X.509 CRL that revokes CAs" to "an X.509 CRL that applies only to CA certificates". This is a clearer description of what an ARL is. * In section 3.4.7, "send the all" should be "send all the". * In section 4.1.1, instead of saying v3 certs must be used for "all but certain self-signed certificates as trust anchors", I think it would be clearer to say "all but self-signed certificates used as trust anchors". * In section 4.1.2.2, "indended" should be "intended". * In section 4.1.3.1, "hierarchies which overly complex" should say "hierarchies which are overly complex" and "such that those" should say "such as those". Similar changes should be made to section 4.1.3.2. * In section 4.1.3.4, you say "the meaning" of the PrivateKeyUsagePeriod extension is unclear in the context of ISAKMP. I think it would be more accurate to say that "the value" of the extension is unclear in this context. The meaning is quite clear. It means that the private key should not be used outside of this period. But because ISAKMP does not involve using a private key at one time and verifying the validity of that usage at a much later time, this extension isn't needed. * In section 4.1.3.7.1, "that the this" should be "that this". Section 4.1.3.7.3 has the same problem. * In section 4.1.3.14, "peer extensions" should be "peer certificates". In the next paragraph, the first sentence should have the word "extension" added to the end. And "IssusingDistributionPoint" should be "IssuingDistributionPoint". Also, I think you mean "a CRL for a different distribution point" instead of "a known good CRL". And the name of the extension is CRLDistributionPoints, not CRLDistributionPoint. This error appears throughout the document. * At the end of section 4.1.3.14, you might want to say "Note that support for the CRLDistributionPoints and IssuingDistributionPoint extensions is RECOMMENDED but not REQUIRED by RFC 3280." This will help people see that they are not required to license any IPR to implement RFC 3280 properly. * In section 4.1.3.16, "the absence knowledge" should be "the absence of knowledge". * In section 4.2, instead of saying "environment that the implementation is used", I suggest the alternate wording "environment where the implementation is used". * In section 4.2.3.1, "hierarchies which overly complex" should be "hierarchies which are overly complex". * In section 4.2.3.5, "and the MUST" should be "MUST".
S/MIME Cryptographic Signature