Looking at http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-10.txt I have some comments.
I think that the whole discussion about multiple Peer and Server-IDs could be reflected better in section 5.2 (last paragraph): OLD: It is possible for more than one subjectAltName field to be present in a peer or server certificate in addition to an empty or non-empty subject distinguished name. EAP-TLS implementations SHOULD export all the subjectAltName fields within Peer-Ids or Server-Ids. If the Subject distinguished name is non-empty then it SHOULD be exported within the Peer-Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are considered valid. It’s good that all available the IDs are being exported, but perhaps we should impose a canonical ordering of those multiple identities. For example by adding "...in the same order in which they appear within the certificate": NEW: It is possible for more than one subjectAltName field to be present in a peer or server certificate in addition to an empty or non-empty subject distinguished name. EAP-TLS implementations SHOULD export all the subjectAltName fields within Peer-Ids or Server-Ids in the same order in which they appear within the certificate. If the Subject distinguished name is non-empty then it SHOULD be exported within the Peer-Ids or Server-Ids. All of the exported Peer-Ids and Server-Ids are considered valid. Such canonical ordering would aid in comparison operations and would enable using those IDs for key derivation if that is deemed useful later on. -gabriel
_______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
