[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 5755

IETF PKIX WG                    Stephen Farrell, Trinity College Dublin
Internet Draft                             Russ Housley, Vigil Security
Intended Status: Standards Track                      Sean Turner, IECA
Updates: 3281 (once approved)                          October 26, 2008
Expires: April 26, 2009



    An Internet Attribute Certificate Profile for Authorization: Update
                     draft-ietf-pkix-3281update-01.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 April 26, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document updates RFC 3281.  It incorporates verified errata.







Turner, et. al.         Expires April 26, 2009                 [Page 1]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


Discussion

   This draft is being discussed on the 'ietf-pkix' mailing list. To
   subscribe, send a message to ietf-pkix-request@imc.org with the
   single word subscribe in the body of the message. There is a Web site
   for the mailing list at <http://www.imc.org/ietf-pkix/>.

1. Introduction

   This document updates [RFC3281].  It incorporates verified errata.
   OLD text is replaced by NEW text.

1.1. Requirements Terminology

   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 [RFC2119].

2. Changes to Section 4.1

   Replace the following ASN.1 excerpt in section 4.1. This change
   incorporates verified technical errata #303.

   NOTE: The "," is moved on the version line.

   OLD:

   AttributeCertificateInfo ::= SEQUENCE {
     version                 AttCertVersion  -- version is v2,
     holder                  Holder,
     issuer                  AttCertIssuer,
     signature               AlgorithmIdentifier,
     serialNumber            CertificateSerialNumber,
     attrCertValidityPeriod  AttCertValidityPeriod,
     attributes              SEQUENCE OF Attribute,
     issuerUniqueID          UniqueIdentifier OPTIONAL,
     extensions              Extensions OPTIONAL
   }











Turner, et al.          Expires April 26, 2009                 [Page 2]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


   NEW:

   AttributeCertificateInfo ::= SEQUENCE {
     version                 AttCertVersion,  -- version is v2
     holder                  Holder,
     issuer                  AttCertIssuer,
     signature               AlgorithmIdentifier,
     serialNumber            CertificateSerialNumber,
     attrCertValidityPeriod  AttCertValidityPeriod,
     attributes              SEQUENCE OF Attribute,
     issuerUniqueID          UniqueIdentifier OPTIONAL,
     extensions              Extensions OPTIONAL
   }

3. Changes to Section 4.3.2

   Replace the OLD text with the NEW text in section 4.3.2.  This
   incorporates verified technical errata #710.

   NOTE: "Confirming" is replaced "Conforming".

   OLD:

   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
   Targets".  Conforming AC issuer implementations MUST only produce one
   "Targets" element.  Confirming AC users MUST be able to accept a
   "SEQUENCE OF Targets".  If more than one Targets element is found in
   an AC, the extension MUST be treated as if all Target elements had
   been found within one Targets element.

   NEW:

   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
   Targets".  Conforming AC issuer implementations MUST only produce one
   "Targets" element.  Conforming AC users MUST be able to accept a
   "SEQUENCE OF Targets".  If more than one Targets element is found in
   an AC, the extension MUST be treated as if all Target elements had
   been found within one Targets element.

4. Changes to Section 4.4.6

   Replace OLD1 text with NEW1 text.  This change incorporates verified
   technical errata #302. Replace OLD2 text with NEW2 text.  This change
   incorporates reported technical errata #1479.

   NOTE for OLD1: The differences in tagging arose due to an unnoticed
   technical corrigendum (TC-2) being applied to the X.501 [X.501-1997]


Turner, et al.          Expires April 26, 2009                 [Page 3]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


   document during preparation of [RFC3281]. The X.501 format is the
   correct form. Implementers SHOULD modify their decoding functions to
   accept either format and, even if claiming RFC 3281 conformance,
   SHOULD output the (correct) X.501 format.

   NOTE for OLD2: The two changes 1) removing the IMPLICIT from the type
   line and 2) adding the EXPLICIT to the value line. Both changes are
   for clarity, for alignment with X.501, and do not change the bits on
   the wire.  With respect to 1) the module uses IMPLICIT tags therefore
   the IMPLICIT in the type line is extraneous and is removed
   2) [1] ANY, [1] EXPLICIT ANY, and [1] IMPLICIT ANY all result in the
   same encoding therefore for alignment purposes with X.501:1997 the
   EXPLICIT is added.

   OLD1:

   Clearance ::= SEQUENCE {
     policyId            [0] OBJECT IDENTIFIER,
     classList           [1] ClassList DEFAULT {unclassified},
     securityCategories  [2] SET OF SecurityCategory  OPTIONAL
   }

   NEW1:

   Clearance ::= SEQUENCE {
     policyId            OBJECT IDENTIFIER,
     classList           ClassList DEFAULT {unclassified},
     securityCategories  SET OF SecurityCategory  OPTIONAL
   }

   OLD2:

   SecurityCategory ::= SEQUENCE {
     type   [0] IMPLICIT OBJECT IDENTIFIER,
     value  [1] ANY DEFINED BY type
   }

   NEW2:

   SecurityCategory ::= SEQUENCE {
     type   [0] OBJECT IDENTIFIER,
     value  [1] EXPLICIT ANY DEFINED BY type
   }






Turner, et al.          Expires April 26, 2009                 [Page 4]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


5. Changes to Section 7.1

   Replace the OLD text with the NEW text.  This change incorporates
   reported technical errata #304.

   OLD:

   The AC then contains the ciphertext inside its signed data.  The
   EnvelopedData (id-envelopedData) ContentType is used, and the content
   field will contain the EnvelopedData type.

   NEW:

   Within EnvelopedData, the encapsulatedContentInfo identifies the
   content type carried withing the ciphertext.  In this case, the
   contentType field of encapsulatedContentInfo MUST contain id-ct-
   attrCertEncAttrs, which has the following value:

     attrCertEncAttrs OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
       id-smime(16) id-ct(1) 14 }

6. Changes to Section 10

   Replace the reference to X.501:1993 to X.501:1997.  This change
   incorporates reported technical errata #1479.

   NOTE: Clearance was defined in X.501:1993 not X.501:1997.

   OLD:

   [X.501-1993]   ITU-T Recommendation X.501 : Information Technology -
                  Open Systems Interconnection - The Directory: Models,
                  1993.

   NEW:

   [X.501-1997]   ITU-T Recommendation X.501 : Information Technology -
                  Open Systems Interconnection - The Directory: Models,
                  1997.

7. Changes to Annex B

   This module replaces the module in Annex B of [RFC3281].  It
   incorporates verified technical errata #302 and #1480 and verified
   editorial errata #303.



Turner, et al.          Expires April 26, 2009                 [Page 5]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


   PKIXAttributeCertificate-2008 { iso(1) identified-organization(3)
     dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-attribute-cert2(TBA) }

   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN

   -- EXPORTS ALL --

   IMPORTS

   -- IMPORTed module OIDs MAY change if [PKIXPROF] changes
   -- PKIX Certificate Extensions

   Attribute, AlgorithmIdentifier, CertificateSerialNumber,
   Extensions, UniqueIdentifier, id-pkix, id-pe, id-kp, id-ad, id-at
     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) }

   GeneralName, GeneralNames, id-ce
     FROM PKIX1Implicit88
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-pkix1-implicit-88(2) }

   ;

   id-pe-ac-auditIdentity       OBJECT IDENTIFIER ::= { id-pe 4 }

   id-pe-aaControls             OBJECT IDENTIFIER ::= { id-pe 6 }

   id-pe-ac-proxying            OBJECT IDENTIFIER ::= { id-pe 10 }

   id-ce-targetInformation      OBJECT IDENTIFIER ::= { id-ce 55 }

   id-aca                       OBJECT IDENTIFIER ::= { id-pkix 10 }

   id-aca-authenticationInfo    OBJECT IDENTIFIER ::= { id-aca 1 }

   id-aca-accessIdentity        OBJECT IDENTIFIER ::= { id-aca 2 }

   id-aca-chargingIdentity      OBJECT IDENTIFIER ::= { id-aca 3 }

   id-aca-group                 OBJECT IDENTIFIER ::= { id-aca 4 }


Turner, et al.          Expires April 26, 2009                 [Page 6]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


   -- { id-aca 5 } is reserved

   id-aca-encAttrs              OBJECT IDENTIFIER ::= { id-aca 6 }

   id-at-role                   OBJECT IDENTIFIER ::= { id-at 72}

   id-at-clearance              OBJECT IDENTIFIER ::= {
     joint-iso-ccitt(2) ds(5) module(1) selected-attribute-types(5)
     clearance (55) }

   -- Uncomment this if using a 1988 level ASN.1 compiler

   -- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING

   AttributeCertificate ::= SEQUENCE {
     acinfo              AttributeCertificateInfo,
     signatureAlgorithm  AlgorithmIdentifier,
     signatureValue      BIT STRING
   }

   AttributeCertificateInfo ::= SEQUENCE {
     version                 AttCertVersion,  -- version is v2
     holder                  Holder,
     issuer                  AttCertIssuer,
     signature               AlgorithmIdentifier,
     serialNumber            CertificateSerialNumber,
     attrCertValidityPeriod  AttCertValidityPeriod,
     attributes              SEQUENCE OF Attribute,
     issuerUniqueID          UniqueIdentifier OPTIONAL,
     extensions              Extensions OPTIONAL
   }

   AttCertVersion ::= INTEGER { v2(1) }

   Holder ::= SEQUENCE {
     baseCertificateID   [0] IssuerSerial OPTIONAL,
            -- the issuer and serial number of
            -- the holder's Public Key Certificate
     entityName          [1] GeneralNames OPTIONAL,
            -- the name of the claimant or role
     objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
            -- used to directly authenticate the
            -- holder, for example, an executable
   }





Turner, et al.          Expires April 26, 2009                 [Page 7]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


   ObjectDigestInfo ::= SEQUENCE {
     digestedObjectType  ENUMERATED {
                          publicKey         (0),
                          publicKeyCert     (1),
                          otherObjectTypes  (2) },
            -- otherObjectTypes MUST NOT
            -- MUST NOT be used in this profile
     otherObjectTypeID   OBJECT IDENTIFIER  OPTIONAL,
     digestAlgorithm     AlgorithmIdentifier,
     objectDigest        BIT STRING
   }

   AttCertIssuer ::= CHOICE {
     v1Form      GeneralNames,  -- MUST NOT be used in this
                                -- profile
     v2Form  [0] V2Form         -- v2 only
   }

   V2Form ::= SEQUENCE {
     issuerName             GeneralNames  OPTIONAL,
     baseCertificateID  [0] IssuerSerial  OPTIONAL,
     objectDigestInfo   [1] ObjectDigestInfo  OPTIONAL
            -- issuerName MUST be present in this profile
            -- baseCertificateID and objectDigestInfo MUST
            -- NOT be present in this profile
   }

   IssuerSerial ::= SEQUENCE {
     issuer     GeneralNames,
     serial     CertificateSerialNumber,
     issuerUID  UniqueIdentifier OPTIONAL
   }

   AttCertValidityPeriod  ::= SEQUENCE {
     notBeforeTime  GeneralizedTime,
     notAfterTime   GeneralizedTime
   }

   Targets ::= SEQUENCE OF Target

   Target ::= CHOICE {
     targetName   [0] GeneralName,
     targetGroup  [1] GeneralName,
     targetCert   [2] TargetCert
   }




Turner, et al.          Expires April 26, 2009                 [Page 8]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


   TargetCert ::= SEQUENCE {
     targetCertificate  IssuerSerial,
     targetName         GeneralName OPTIONAL,
     certDigestInfo     ObjectDigestInfo OPTIONAL
   }

   IetfAttrSyntax ::= SEQUENCE {
     policyAuthority [0] GeneralNames OPTIONAL,
     values          SEQUENCE OF CHOICE {
                       octets  OCTET STRING,
                       oid     OBJECT IDENTIFIER,
                       string  UTF8String
     }
   }

   SvceAuthInfo ::= SEQUENCE {
     service   GeneralName,
     ident     GeneralName,
     authInfo  OCTET STRING OPTIONAL
   }

   RoleSyntax ::= SEQUENCE {
     roleAuthority  [0] GeneralNames OPTIONAL,
     roleName       [1] GeneralName
   }

   Clearance ::= SEQUENCE {
     policyId            OBJECT IDENTIFIER,
     classList           ClassList DEFAULT {unclassified},
     securityCategories  SET OF SecurityCategory  OPTIONAL
   }

   ClassList ::= BIT STRING {
     unmarked      (0),
     unclassified  (1),
     restricted    (2),
     confidential  (3),
     secret        (4),
     topSecret     (5)
   }

   SecurityCategory ::= SEQUENCE {
     type   [0] OBJECT IDENTIFIER,
     value  [1] EXPLICIT ANY DEFINED BY type
   }




Turner, et al.          Expires April 26, 2009                 [Page 9]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


   AAControls ::= SEQUENCE {
     pathLenConstraint      INTEGER (0..MAX) OPTIONAL,
     permittedAttrs     [0] AttrSpec OPTIONAL,
     excludedAttrs      [1] AttrSpec OPTIONAL,
     permitUnSpecified      BOOLEAN DEFAULT TRUE
   }

   AttrSpec ::= SEQUENCE OF OBJECT IDENTIFIER

   ACClearAttrs ::= SEQUENCE {
     acIssuer  GeneralName,
     acSerial  INTEGER,
     attrs     SEQUENCE OF Attribute
   }

   ProxyInfo ::= SEQUENCE OF Targets

   END

8. Security Considerations

   The security considerations in [RFC3281] apply.  No new security
   considerations are added as a result of this document.

9. IANA Considerations

   This document makes extensive use of object identifiers to register
   extensions and attributes.  Most are registered in an arc delegated
   by IANA to the PKIX Working Group.  Other are taken from ITU-T | ISO
   arc.  Additionally, an object identifier is used to identify the
   ASN.1 module found in Section 7.  No further action by IANA is
   necessary for this document or any anticipated updates.

10. References

10.1. Normative

   [PKIXPROF]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.
   Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure
   Certificate and Certificate Revocation List (CRL) Profile", RFC 5280,
   May 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3281]  Farrell, S., and R. Housley, "An Internet Attribute
   Certificate Profile for Authorization", RFC 3281, April 2002.


Turner, et al.          Expires April 26, 2009                [Page 10]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


   [X.501-1997]  ITU-T Recommendation X.501: Information Technology -
   Open Systems Interconnection - The Directory: Models, 1997.

10.2. Informative

   None.

Author's Addresses

   Sean Turner

   IECA, Inc.
   3057 Nutley Street, Suite 106
   Fairfax, VA 22031
   USA

   Email: turners@ieca.com

   Russ Housley

   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: housley@vigilsec.com

   Stephen Farrell

   Distributed Systems Group
   Computer Science Department
   Trinity College Dublin
   Ireland

   Email: stephen.farrell@cs.tcd.ie














Turner, et al.          Expires April 26, 2009                [Page 11]

Internet-Draft   Update: An Internet Attribute Certificate     Oct 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Turner, et al.          Expires April 26, 2009                [Page 12]

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/