To refresh people's memories, here is what is in Section 5.2:
5.2. Peer and Server Identities The EAP-TLS peer name (Peer-Id) represents the identity to be used for access control and accounting purposes. The Server-Id represents the identity of the EAP server. In EAP-TLS, the Peer-Id and Server-Id are determined from the subject or subjectAltName fields in the peer and server certificates. For details, see [RFC3280] Section 4.1.2.6. Where the subjectAltName field is present in the peer or server certificate, the Peer-Id or Server-Id MUST be set to the contents of the subjectAltName as described in Section 5.3. If subject naming information is present only in the subjectAltName extension of a peer or server certificate, then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical. Although the use of the subject name field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. Where it is non-empty, the subject name field MUST contain an X.500 distinguished name (DN). Where the peer identity represents a host, a subjectAltName of type dnsName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. If a dnsName or rfc822Name are not available other field types (for example a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used. A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dnsName SHOULD be present in the server certificate. If a dnsName is not available other field types (for example a subjectAltName of type ipAddress or uniformResourceIdentifier) MAY be used. If subject naming information is present only in the subject name field and the peer identity represents a user, then the subject name field SHOULD contain an emailAddress RDN. If the peer identity represents a host or device the subject name field SHOULD contain a CN RDN or serialNumber RDN. If subject naming information is present only in the subject name field of a server certificate, then the subject name field MUST contain a CN RDN or serialNumber RDN.
From: "Joseph Salowey (jsalowey)" <[EMAIL PROTECTED]> To: <[email protected]> Subject: [Emu] RFC 2716bis Section 5.2. Peer and Server Identities Date: Mon, 16 Apr 2007 08:52:19 -0700 At the meeting in Prague we had some discussion on the contents of section 5.2 of RFC2716bis. Section 5.2 of draft-simon-emu-rfc2716bis-08.txt looks to be acceptable according to the discussion. Do people approve of or object to the text in section 5.2? _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
