Couple of comments about draft-ietf-pki4ipsec-ikecert-profile-10, all fairly minor: 1) Section 3.1: "Implementations SHOULD populate ID with identity information that is contained within the end-entity certificate [...] The only case where implementations MAY populate ID with information that is not contained in the end-entity certificate is when ID contains the peer source address (a single address, not a subnet or range)." The part "the only case where implementations MAY [do X] is when [condition]" is not consistent with the RFC 2119 definition of MAY (or at least, it's very confusing). Is the intention to say "One case where implementatations MAY [do X] is when [condition]", or "Implementations MUST NOT [do X] unless [condition]", or possibly something else? 2) Section 3.1.2 (and also the same text in 3.1.3): "However, implementations SHOULD NOT use the DNS to map the FQDN to IP addresses for input into any policy decisions, unless that mapping is known to be secure, for example if DNSSEC [12] were employed for that FQDN. If the FQDN in question is owned by the attacker, then even DNSSEC does not guarantee that the IP address is something that should be used as an input to policy decisions. 3) The profile contains some recommendations about CERTREQ processing that are not fully in line with what IKEv2 recommends. In particular, Section 3.3.7 says that "Implementations that receive CERTREQs from a peer which contain only unrecognized Certification Authorities SHOULD NOT continue the exchange". But RFC 4306 Section 3.7 (last paragraph) seems to recommend that if the contains of CERTREQ are not helpful in selecting which certificate to send, its contents should be just ignored. The latter behavior is especially sensible for IKEv2 where the CERTREQ contains hashes of CA public keys (instead of distinguished names), since the peer does not necessarily have those public keys at all (it doesn't need to verify its own certificate, and might be using other trust anchors/other methods that certificates to authenticate the other peer). 4) Also, Section 3.2.7 says that "When in-band exchange of certificate keying materials is desired, implementations MUST inform the peer of this by sending at least one CERTREQ. In other words, an implementation which does not send any CERTREQs during an exchange SHOULD NOT expect to receive any CERT payloads." It should be noted that RFC 4306 Sections 3.6 (first paragraph) and 3.7 (first paragraph) recommend sending certificates if available, and suggest that CERTREQ expresses preferences about certification authorities (and sending one would be optional even if CERT payloads are needed for authentication). 5) Section 7.1: "The Contents of CERTREQ are not encrypted in IKE." The initiator's CERTREQ is encrypted in IKEv2 (but since it's naturally sent before the initiator has authenticated the responder, this helps only against passive eavesdroppers). 6) Throughout the document: "caseless" -> "case-insensitive" 7) References: RFCs 2314 and 2535 have been obsoleted by newer RFCs. Best regards, Pasi _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf