Subject: [Emu] RFC 2716bis Section 5.2. Peer and Server Identities

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
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-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 16 Apr 2007 11:25:27 -0700

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-masked]>
>To: <[email-masked]>
>Subject: [Emu] RFC 2716bis Section 5.2.  Peer and Server Identities
>Date: Mon, 16 Apr 2007 08:52:19 -0700
>