5.1 Web Server with Client Certificates   In one particular web-based system which depends upon client   certificates for authentication, there are four distinct actions that   have to take place before a user is fully enrolled (i.e.  before   client certificate authorization can take place automatically).   First, a user must have a client certificate issued.  Second, the   administrator must create an account for the user.  Third, the   administrator of the web service must issue a userid and password for   that service account to the user.  Finally, the user connects to a   secure web page which does a client certificate SSL/TLS exchange.   If the web server has a mapping between a userid and this certificate   already the interaction is complete and the access rights of the   mapped userid are used when considering access to the resources.   Otherwise, the web server prompts for a userid and password which is   then validated.  If valid, the web server stores the userid/   certificate mapping for future reference as above.  This last step,   in conjunction with the client certificate exchange results in a   semi-permanent mapping between the client certificate and the userid.   In later interactions between client and server, the client may do   automatic client side authentication using its certificate-based   credential.  The user is granted access to whatever resources the   access control system permissions allow for the userid which is   associated with the client (user) certificate.   In a UserGroupName alternative for this, the user is issued a   credential consisting of an X.509 certificate with an appropriate   UserGroupName SANE and its associated private key.  The credential   can be issued in many ways including at least through a certificate   signing request, central generation (e.g.  a PKCS12 blob), or through   the distribution of a hardware token.  The administrator must also   still create an account on the service.  Upon connection to the   protected server, the userid (and/or the groups field if permitted by   policy) is extracted from the validated client certificate and used   as the basis for access control decisions.  The process of issuing a   PKCS12 blob (containing certificate and private key) or hardware   token is roughly equivalent to the single step of issuing a userid   and password as described above.   As an alternative to having an administrator explicitly create an   account for a user, the policy of the web server could allow an   account to be created based on the contents of the group field of the   UserGroupName.  In other words, the web server consults the group   field once during the first interaction between the user and the   server.  If the interaction is authenticated and policy authorizes   it, the web server can create an account specific to the useridStJohns                  Expires March 26, 2003                 [Page 8]Internet-Draft             PKIX UserGroupName             September 2002   contained within the user certificate.  The groups field is not   consulted once the server creates the account.6. Security Considerations   The use of the UserGroupName in most situations has roughly the same   level of threat as that for any X.509 certificate and the Security   Considerations text in [RFC3280] is applicable.  However, the use of   the groups element of the UserGroupName may have some unforeseen side   effects in certain systems.   The user tags (along with the private keys of the certificates) are   just credentials.  They can be used to prove the identity of a   client, but don't of themselves grant a client access to data or   other resources.  An access control system is used to map credentials   to rights.  Revocation of access of a client to a resource is as   simple as removing or changing the access control entry and doesn't   necessarily require the use of a Certificate Revocation List (CRL) to   revoke the certificate.  Indeed, the revocation of the certificate   may be undesirable as the removal of access may be only temporary.   However, the use of group tags is problematic in systems which do not   consider Certificate Revocation Lists as part of their path   validation processing.  Since group access by definition covers a   group of people, its difficult or impossible to remove access for a   single member of the group without removing the user from the group.   If the group information is encoded in the certificate, use of CRLs   is pretty much mandatory.   One possible approach where groups are desired, but CRLs are not   available is to not encode the group information within the   certificate.  Instead, do the user to group mapping as part of the   access control processing (ala Unix).  In that manner, a user could   be deleted from a group simply by updating the user to group mappings   on all accepting systems.  Another related approach might be to have   a user and group hotlist where you would add a user only if you   wanted to remove them from a group that's listed in the client   certificate.7. Design Discussion   There are many possible ways of accomplishing the goals of directly   encoding user and group information within a certificate.  This   section provides some insight into the author's reasoning to adopt   the otherName approach.StJohns                  Expires March 26, 2003                 [Page 9]Internet-Draft             PKIX UserGroupName             September 20027.1 Attribute Certificate   Attribute certificates (ACs) were offered by a couple of members of   the PKIX community as one solution for this problem.  The argument   was made that attribute certificates were the appropriate approach   for things that looked like authorization tokens.   This approach was rejected for a couple of reasons.  First, that ACs   had no defined mechanism for encoding the user and group information.   This otherName extension would still be required to provide the   encoding.  Second, ACs were neither in wide use, nor widely   understood.  Without this knowledge, there is a lack of software on   both the issuer and acceptor ends which could deal with the ACs.   Third, the author didn't completely agree with the argument that   userid and group credentials are authorization tokens.  Userid and   group assignments for most users tend to be fairly static.  The   author, for example, held the same userid and the same group   assignments for over four years at his previous job.  (Except, see   Section 6 above.)   If ACs gain acceptability, there should be no bars to incorporating   this otherName extension as one of the possible attributes allowed   within an AC.7.2 Certificate Extension   The approach of encoding the user and group information as a new   CertificateExtension was initially attractive for a number of   reasons.  First, most software and toolkits had at least rudimentary   support for new extensions.  Second, the actual ASN1 encoding of the   information was a bit less clumsy than if encoded as an otherName.   This option was also rejected when the author tried to consider the   interactions between this extension, the Subject and IssuerNames, and   the Subject and IssuerAltName extensions.  Having a third place for   possibly authoritative name information might make the rules for   resolving which name should be used for various authorization   activities a bit difficult.7.3 otherName GeneralName type   Encoding the user and group information as an otherName appears to be   the mostly right choice.  It doesn't add additional extensions which   might further conflict with the SubjectName field and SubjectAltName   extension.  The usage is well within the appropriate field of use for   the otherName type.ReferencesStJohns                  Expires March 26, 2003                [Page 10]Internet-Draft             PKIX UserGroupName             September 2002   [RFC1035]  Mockapetris, P., "Domain names - implementation and              specification", STD 13, RFC 1035, November 1987.   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels", BCP 14, RFC 2119, March 1997.   [RFC2246]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.              and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,              January 1999.   [RFC3280]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet              X.509 Public Key Infrastructure Certificate and              Certificate Revocation List (CRL) Profile", RFC 3280,              April 2002.Author's Address   Michael StJohns   Network Associates Labs   15204 Omega Drive   Rockville, MD  20850   USA   Phone: +1-301-947-7162   EMail: msj@tislabs.comAppendix A. ASN.1 Definitions   N.B.  Any assignments within this section should not be relied upon   until and if this document is published either as an experimental RFC   or until it enters the standards track.A.1 1988 Module   PKIXusergroup {iso(1) identified-organization(3) dod(6)          internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)          id-mod-user-group (20) }   DEFINITIONS EXPLICIT TAGS ::=      BEGIN      -- EXPORTS ALL --      IMPORTSStJohns                  Expires March 26, 2003                [Page 11]Internet-Draft             PKIX UserGroupName             September 2002           id-pkix, AttributeType, UTF8String                   FROM PKIX1Explicit88 {iso(1) identified-organization(3)                   dod(6) internet(1) security(5) mechanisms(5) pkix(7)                   id-mod(0) id-pkix1-explicit-88(1)}      -- Object Identifiers      -- Externally defined OIDs      -- Arc for other name forms      id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }      -- userGroupName      id-on-userGroup   AttributeType ::= { id-on 2 }      UserGroupName ::=     SEQUENCE {              domain     UTF8String,              user       UTF8String,              groups     SEQUENCE OF UTF8String OPTIONAL      }   ENDStJohns                  Expires March 26, 2003                [Page 12]Internet-Draft             PKIX UserGroupName             September 2002A.2 Notional ASN.1 Encoding   The following represents how a UserGroupName otherName would be   encoded within an SubjectAltName Extension.  The notation "'[" means   to encode the enclosed items and return the octets.   [SEQUENCE                              -- Extension     OID            id-ce-subjectAltName  -- extnID     BOOLEAN        true                  -- critical     OCTET STRING                         -- extnValue        -- Encode the following and provide as value for OCTET STRING      '[SEQUENCE                          -- GeneralNames         [0                               -- otherName type tag           [SEQUENCE                      -- otherName             OID    id-on-userGroup       -- type-id             [0               [SEQUENCE                  -- UserGroupName                 UTF8String  'tislabs.com' -- domain                 UTF8String  'stjohns'    -- userid                 [SEQUENCE OF             -- groups                   UTF8String  'system'                   UTF8String  'atg'                 ]               ]             ]           ]         ]       ]'   ]StJohns                  Expires March 26, 2003                [Page 13]Internet-Draft             PKIX UserGroupName             September 2002Full Copyright Statement   Copyright (C) The Internet Society (2002).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.StJohns                  Expires March 26, 2003                [Page 14]