Paul Hoffman writes:
> Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN,
ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and
ID_KEY_ID), and then says:
>
> Two implementations will interoperate only if each can generate a type of
ID acceptable to the other. To assure maximum interoperability,
implementations MUST be configurable to send at least one of ID_IPV4_ADDR,
ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept
all of these types. Implementations SHOULD be capable of generating and
accepting all of these types. IPv6-capable implementations MUST additionally
be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be
configurable to send only ID_IPV6_ADDR.
>
> What does "Implementations SHOULD be capable of generating and accepting
all of these types" mean? It can't mean the four just listed, because that
list of four comes with MUSTs. If it means all the listed types, the
sentence should be changed to "Implementations SHOULD also be capable of
generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and ID_DER_ASN1_GN."
In addition, this is inconsistent with section 4 (Conformance Requirements),
which states:
For an implementation to be called conforming to this specification,
it MUST be possible to configure it to accept the following:
o PKIX Certificates containing and signed by RSA keys of size 1024
or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
ID_RFC822_ADDR, or ID_DER_ASN1_DN.
o Shared key authentication where the ID passed is any of ID_KEY_ID,
ID_FQDN, or ID_RFC822_ADDR.
o Authentication where the responder is authenticated using PKIX
Certificates and the initiator is authenticated using shared key
authentication.
Regards,
Valery Smyslov.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
