draft-ietf-pkix-usergroup-01.txt

来自「PKIX的RFC英文文档」· 文本 代码 · 共 785 行 · 第 1/2 页

Network Working Group                                         M. StJohns
Internet-Draft                                   Network Associates Labs
Expires: March 26, 2003                               September 25, 2002


                The PKIX UserGroupName GeneralName Type
                      draft-ietf-pkix-usergroup-01

Status 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.

Conformance



StJohns                  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 . . . . . . . . . . . . . . . . . . . 14























StJohns                  Expires March 26, 2003                 [Page 2]

Internet-Draft             PKIX UserGroupName             September 2002


1. 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 fields



StJohns                  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. Usage

3.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 ordered



StJohns                  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 Considerations

4.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