[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comments on draft-ietf-ipsec-pki-profile-03.txt



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".

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature