Network Working Group                                         M. StJohnsInternet-Draft                                   Network Associates LabsExpires: March 26, 2003                               September 25, 2002                The PKIX UserGroupName GeneralName Type                      draft-ietf-pkix-usergroup-01Status of this Memo   This document is an Internet-Draft and is in full conformance with   all provisions of Section 10 of RFC2026.   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF), its areas, and its working groups.  Note that   other groups may also distribute working documents as Internet-   Drafts.   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time.  It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as "work in progress."   The list of current Internet-Drafts can be accessed at http://   www.ietf.org/ietf/1id-abstracts.txt.   The list of Internet-Draft Shadow Directories can be accessed at   http://www.ietf.org/shadow.html.   This Internet-Draft will expire on March 26, 2003.Copyright Notice   Copyright (C) The Internet Society (2002).  All Rights Reserved.Abstract   A number of systems which understand X.509 client certificates have   developed various ad hoc mechanisms to map a certificate to a   'userid'/'group(s)' value which can then be used for access control.   The mechanisms include idiosyncratic name forms for the SubjectName   field such as encoding the userid as a CommonName and the group as an   OrganizationalUnit, or mapping the certificate against an entry in a   directory system.  This document describes an otherName extension of   the GeneralName type which can be used in the SubjectAltName   extension or IssuerAltName extension to directly encode userid and   group information.ConformanceStJohns                  Expires March 26, 2003                 [Page 1]Internet-Draft             PKIX UserGroupName             September 2002   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this   document are to be interpreted as described in RFC 2119 [RFC2119].Table of Contents   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3   2.  Definition . . . . . . . . . . . . . . . . . . . . . . . . . .  3   3.  Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4   3.1 Use Within a Leaf (End User) Certificate . . . . . . . . . . .  4   3.2 Use Within an Intermediate (CA) Certificate  . . . . . . . . .  5   4.  Path Validation Considerations . . . . . . . . . . . . . . . .  5   4.1 Trust Mappings . . . . . . . . . . . . . . . . . . . . . . . .  5   4.2 Domain Matching  . . . . . . . . . . . . . . . . . . . . . . .  6   4.3 Multiple UserGroupNames  . . . . . . . . . . . . . . . . . . .  7   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  7   5.1 Web Server with Client Certificates  . . . . . . . . . . . . .  8   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9   7.  Design Discussion  . . . . . . . . . . . . . . . . . . . . . .  9   7.1 Attribute Certificate  . . . . . . . . . . . . . . . . . . . . 10   7.2 Certificate Extension  . . . . . . . . . . . . . . . . . . . . 10   7.3 otherName GeneralName type . . . . . . . . . . . . . . . . . . 10       References . . . . . . . . . . . . . . . . . . . . . . . . . . 11       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11   A.  ASN.1 Definitions  . . . . . . . . . . . . . . . . . . . . . . 11   A.1 1988 Module  . . . . . . . . . . . . . . . . . . . . . . . . . 11   A.2 Notional ASN.1 Encoding  . . . . . . . . . . . . . . . . . . . 13       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14StJohns                  Expires March 26, 2003                 [Page 2]Internet-Draft             PKIX UserGroupName             September 20021. Introduction   This document defines a proposed extension of the acceptable   otherName instantiations of the GeneralName type within the Subject   and IssuerAltName extensions described in [RFC3280].  It is   applicable to the X.509 Public Key Infrastructure for the Internet   family of standards.  The definitions described herein extend and   depend on those described in RFC 3280 which, in turn, defines the   underlying certificate formats needed for a full implementation of   this otherName definition.   This document describes a method of encoding Unix-style userid and   group information directly within an X.509 certificate.  Currently, a   number of systems (e.g.  web servers which accept or depend upon SSL/   TLS [RFC2246] client certificate authentication) use ad hoc methods   for either mapping from or encoding names within the X.509   SubjectName RDN (Relative Distinguished Name).  For example, one   system uses a CommonName element within the SubjectName to represent   a userid and an OrganizationalUnit element to represent one or more   groups.  Another system stores a mapping from a particular   certificate to a set of userid and group information within an LDAP   database.  Neither of the above approaches are standardized, nor are   they substantially interoperable across many systems.   The approach described in this document does not necessarily enable   any additional functionality over that available in existing systems.   However, it does standardize and specify a single common encoding for   userid and group names and this appears to be a useful goal.  Code   and products which work across a broad spectrum of applications can   be designed once a standard semantic and syntactic definition exists.2. Definition   This name is defined as a form of otherName from the GeneralName   structure in SubjectAltName.  The basic definition of the   UserGroupName type is:   id-on-userGroup   AttributeType ::= { id-on 2 }   UserGroupName ::=     SEQUENCE {              domain            UTF8String,              user              UTF8String,              groups            SEQUENCE OF UTF8String OPTIONAL   }   The UserGroupName otherName consists of three fields:   o  The domain field indicates the domain under which the other fieldsStJohns                  Expires March 26, 2003                 [Page 3]Internet-Draft             PKIX UserGroupName             September 2002      are evaluated.  Although it is encoded as a UTF8String to permit      future expansion, by convention this SHOULD be specified as a      valid, '.' (dot) separated tokens, domain name system (DNS) style      domain name.  The domain is used to differentiate userids on      various systems and within various organizations.  For example,      'smith' on the host yoohoo.entera.com might be different than      'smith' on the host (or within the domain) bigbank.org.  See      Section 4 below for more information on the treatment of the      domain field.   o  The user field encodes the userid represented by this certificate      within the domain specified.  In general, this SHOULD be in the      subset of UTF8 common to the target domain.   o  The groups field is optional and encodes the groups the holder of      this certificate is permitted access to within the specified      domain.  As above, this SHOULD be in the subset of UTF8 common to      the target domain.3. Usage3.1 Use Within a Leaf (End User) Certificate   For an end user certificate (i.e.  a client certificate), the   UserGroupName element is encoded within a SubjectAltName extension   (SANE).  The SANE SHOULD be marked as critical, and MUST be marked as   critical if the SubjectName field is empty.   The UserGroupName represents an identity for the certificate.  In   general, there SHOULD NOT be any other non-UserGroupName names within   the SANE and the SubjectName field SHOULD be empty.  If a leaf   certificate with both a SubjectName and a UserGroupName OtherName   SANE is presented, the certificate SHOULD be considered invalid for   the purposes of determining a userid or group mapping.   NOTE: Multiple UserGroupName elements are permitted with the SANE of   a leaf certificate.  Each is valid as an identity if and only if the   acceptor can establish that the client certificate chains back to a   CA certificate with a trust relationship for the domain indicated in   that UserGroupName element.  For any given acceptor context where the   client certificate has multiple UserGroupNames, some of the   UserGroupNames may be valid and some may not.   The selection of which of a number of valid UserGroupName elements is   accepted by the server or other acceptor is an implementation   decision.  Possibilities include accepting the userid with the most   access, with the least access, prioritizing it based on an orderedStJohns                  Expires March 26, 2003                 [Page 4]Internet-Draft             PKIX UserGroupName             September 2002   list of domains or only accepting a specific single domain.3.2 Use Within an Intermediate (CA) Certificate   For a CA certificate, one or more UserGroupName otherNames MAY be   included within a SANE.  The SANE MUST be marked as critical in that   event.  The inclusion of the UserGroupName element acts to restrict   the set of groups which this CA (and its subsidiary CA's) may   certify.  The userid field MAY be non-empty, but is ignored for most   purposes.  If a UserGroupName element is present in the SANE of a CA   certificate, then the BasicConstraints extension MUST also be   included and the BasicConstraints.cA flag MUST be set to true.   As per normal usage, the contents of the issuer's SANE are generally   copied to the IssuerAltName extension of an issued certificate as   part of the certificate signature process.  However, only the   UserGroupName SANEs are consulted during UserGroupName path   validation.   N.B.: A certificate where the BasicConstraints.cA flag is set to true   MUST NOT be accepted as a client or leaf certificate for the purposes   of UserGroupName processing.4. Path Validation Considerations4.1 Trust Mappings   Each system (server, application) which accepts certificates with a   UserGroupName element within the certificate's SANE must establish   one or more trust mappings between the specified domain tags and root   or intermediate CA certificates.  During path validation, the   accepting system MUST verify that the offered certificate chains back   to a root or intermediate CA that has a trust mapping which contains   the certificate's SubjectAltName UserGroup domain.   The specific mechanism for establishing or describing the trust   mapping is outside of the scope of this document.  However, it could   be something as simple as a text file with the first column listing   the domain and the second column listing a certificate fingerprint.            labs.nai.com  \               1B:D1:AD:17:8B:7F:22:13:24:F5:26:E2:5D:4E:B9:10            tislabs.com  \               63:1B:66:93:8C:F3:66:CB:3C:79:57:DC:05:49:EA:DB   Another possibility might be to identify the trusted certificate by   subjectName and the subjectKeyIdentifier.  This latter approach may   be more useful as it allows expired roots to be easily superceded.StJohns                  Expires March 26, 2003                 [Page 5]Internet-Draft             PKIX UserGroupName             September 2002   In addition to establishing a mapping between a trust root and a   domain, each implementing acceptor must decide whether to accept all,   some or none of the validated group information as authoritative.   Again, the specific mechanism for describing this is outside the   scope of the document, but SHOULD include a global on/off switch for   group processing which defaults to off (i.e.  group information is   not provided to the acceptor); an on/off switch for group processing   for each trust anchor which defaults to off; and the ability to limit   the groups accepted by each trust anchor to a specific maximum set or   to prohibit a set of groups.  See Section 6 below for discussion of   the appropriate use of group information.     :groups=true     labs.nai.com 1B:..:10 [ANY:^system:^wheel]     tislabs.com  63:..:DB []4.2 Domain Matching   As mentioned above, the domain field SHOULD be a DNS structured, dot   separated string (see 2.3.1 in [RFC1035]).  To be valid a client   certificate MUST chain back to a trusted certificate where the domain   specified by the trust mapping is either equal to the domain of the   client certificate or contains the domain of the client certificate.   The specific matching algorithm is:   if trustDomain(CA) == userGroupName.domain      then match   else if  tail (userGroupName.domain, length(trustDomain(CA))+1) ==            concat (".", trustDomain)      then match   else no match   trustDomain(CA) looks up the domain for the root      certificate's trust mapping   tail (string, len) returns the last len characters of a string   concat (string,string) returns a concatenation of two strings   The addition of the '.' (dot) to the trust domain in the algorithm   ensures that an invalid match like "mystupiddomain.com" matching   "stupiddomain.com" doesn't happen.  Also, as is normal for DNS style   names, matching is done without respect to case.  Note that there may   be multiple trust mappings for a single root and that all MUST be   tried for the match.   Obviously, using the above matching algorithm,  if the   userGroupName.domain does not contain a '.', the only match possible   is an exact match.StJohns                  Expires March 26, 2003                 [Page 6]Internet-Draft             PKIX UserGroupName             September 2002   Note: The matching algorithm will need to be readdressed when and if   a standard for internationalized domain names is completed and   approved.  The specific phrase "without respect to case" may be   meaningless or may not have a simple canonical resolution in some   character sets or under some languages.4.3 Multiple UserGroupNames   CA certificates may contain a SANE with one or more UserGroupNames   with a non-null domain and a empty or non-empty set of groups.  If a   CA certificate does have a such a SANE, it acts to restrict the set   of groups that can be 'certified' by that CA certificate.  The final   set of groups output from the path validation processing of the   UserGroupName elements is the MIN of the sets of all the group   elements from each UserGroupName (and, if specified, from the group   list for root trust mapping).  The algorithm is:   for each UserGroupName (UGN) in the client certificate SANE     set maxGroups to client's UGN.groups     for each UGN in the CA certificate in the path        if the CA's UGN.domain contains or equals the clients UGN.domain            then set maxGroups to MIN (maxGroups, CAs UGN.groups,                                           [trustRoot(CA).groups])     output {domain, maxGroups and userid}   For example, the client has a certificate issued by his host with a   UserGroupName containing a  user of 'stjohns', a group field of   ['system', 'security', 'atg'], and a domain field of 'labs.nai.com'.   It validly chains back to a root CA certificate that has a trust   relationship for 'nai.com'.  The CA which signed the client   certificate has a SANE with one UserGroupName containing a domain of   'nai.com' and groups of ['system', 'atg', 'admin'] and another   UserGroupName containing a domain of 'labs.nai.com' with groups of   ['atg'].  The certificate would be valid for the domain   'labs.nai.com', the user 'stjohns' and the groups ['atg'].5. Scenarios   Userids are used as a compact representation of identity on computer   systems.  It's generally much easier to remember "stjohns" than   UID:23645 or a certificate finger print.  It's also easier to use the   userid (vice the other identity forms) as a handle for creating,   deleting, or evaluating an access control entry.  The UserGroupName   provides a straightforward way to map a certificate into a userid.   The following section suggests some possible applications for the   UserGroupName approach to certificate/userid mapping.StJohns                  Expires March 26, 2003                 [Page 7]Internet-Draft             PKIX UserGroupName             September 2002