GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4476

Network Working Group C. Francis Request for Comments: 4476 Raytheon Category: Standards Track D. Pinkas

                                                                  Bull
                                                              May 2006
           Attribute Certificate (AC) Policies Extension

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document describes one certificate extension that explicitly
 states the Attribute Certificate Policies (ACPs) that apply to a
 given Attribute Certificate (AC).  The goal of this document is to
 allow relying parties to perform an additional test when validating
 an AC, i.e., to assess whether a given AC carrying some attributes
 can be accepted on the basis of references to one or more specific
 ACPs.

Francis & Pinkas Standards Track [Page 1] RFC 4476 AC Policies Extension May 2006

1. Introduction

 When issuing a Public Key Certificate (PKC), a Certificate Authority
 (CA) can perform various levels of verification with regard to the
 subject identity (see [RFC3280]).  A CA makes its verification
 procedures, as well as other operational rules it abides by,
 "visible" through a certificate policy, which may be referenced by a
 certificate policies extension in the PKC.
 The purpose of this document is to define an Attribute Certificate
 (AC) policies extension able to explicitly state the AC policies that
 apply to a given AC, but not the AC policies themselves.  Attribute
 Certificates are defined in [RFC3281].

1.1. Conventions Used in This Document

 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. AC Policies Extension Semantics

 An Attribute Certificate Policy is a named set of rules that
 indicates the applicability of an AC to a particular community and/or
 class of applications with common security requirements.  It defines
 rules for the generation, issuance, and revocation of ACs.  It may
 also include additional rules for attributes registration.
 Thus, note that an Attribute Authority (AA) does not necessarily
 support one single ACP.  However, for each AC that is delivered, the
 AA SHALL make sure that the policy applies to all the attributes that
 are contained in it.
 An ACP may be used by an AC user to decide whether or not to trust
 the attributes contained in an AC for a particular purpose.
 When an AC contains an AC policies extension, the extension MAY, at
 the option of the AA, be either critical or non-critical.
 The AC Policies extension MAY be included in an AC.  Like all X.509
 certificate extensions [X.509], the AC policies extension is defined
 using ASN.1 [ASN1].  See Appendix A.
 The definitions are presented in the 1988 Abstract Syntax Notation
 One (ASN.1) rather than the 1997 ASN.1 syntax used in the most recent
 ISO/IEC/ITU-T standards.
 The AC policies extension is identified by id-pe-acPolicies.

Francis & Pinkas Standards Track [Page 2] RFC 4476 AC Policies Extension May 2006

    id-pe-acPolicies OBJECT IDENTIFIER ::= { iso(1)
      identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) id-pkix(7) id-pe(1) 15 }
 The AC policies extension includes a list of AC policies recognized
 by the AA that apply to the attributes included in the AC.
 AC Policies may be defined by any organization with a need.  Object
 identifiers used to identify AC Policies are assigned in accordance
 with [X.660|ISO9834-1].
 The AC policies extension in an AC indicates the AC policies for
 which the AC is valid.
 An application that recognizes this extension and its content SHALL
 process the extension regardless of the value of the criticality
 flag.
 If the extension is both flagged non-critical and not recognized by
 the AC-using application, then the application MAY ignore it.
 If the extension is marked critical or is recognized by the AC-using
 application, it indicates that the attributes contained in the
 attribute certificate SHALL only be used for the purpose, and in
 accordance with the rules associated with one of the indicated AC
 policies.  If none of the ACP identifiers is adequate for the
 application, then the AC MUST be rejected.
 If the extension is marked critical or is recognized by the AC using
 application, the AC-using application MUST use the list of AC
 policies to determine whether it is appropriate to use the attributes
 contained in that AC for a particular transaction.  When the
 appropriate policy is not found, the AC SHALL be rejected.

2.1. AC Policy Extension Syntax

 The syntax for the AC Policy extension is:
 AcPoliciesSyntax ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation
 PolicyInformation ::= SEQUENCE {
     policyIdentifier      AcPolicyId,
     policyQualifiers      SEQUENCE SIZE (1..MAX) OF
                                    PolicyQualifierInfo OPTIONAL}
 AcPolicyId ::= OBJECT IDENTIFIER

Francis & Pinkas Standards Track [Page 3] RFC 4476 AC Policies Extension May 2006

  PolicyQualifierInfo ::= SEQUENCE {
       policyQualifierId  PolicyQualifierId,
       qualifier          ANY DEFINED BY policyQualifierId }
  1. - policyQualifierIds for Internet policy qualifiers
  id-qt            OBJECT IDENTIFIER ::=  { id-pkix 2 }
  id-qt-acps       OBJECT IDENTIFIER ::=  { id-qt 4 }
  id-qt-acunotice  OBJECT IDENTIFIER ::=  { id-qt 5 }
  id-qt-acps OBJECT IDENTIFIER ::= { iso(1)
    identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) id-pkix(7) id-qt(2) 4 }
  id-qt-acunotice OBJECT IDENTIFIER ::= { iso(1)
    identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) id-pkix(7) id-qt(2) 5 }
  PolicyQualifierId ::=
       OBJECT IDENTIFIER ( id-qt-acps | id-qt-acunotice )
  1. - ACPS pointer qualifier
 ACPSuri ::= IA5String
 -- ACP statement user notice qualifier
 ACUserNotice ::= UserNotice
 -- UserNotice is defined in [RFC3280]
 To promote interoperability, this document RECOMMENDS that policy
 information terms consist of only an object identifier (OID).  When
 more than one policy is used, the policy requirements have to be
 non-conflicting, e.g., one policy may refine the general requirements
 mandated by another policy.
 The extension defined in this specification supports two policy
 qualifier types for use by ACP writers and AAs.  The qualifier types
 are the ACPS Pointer and the AC User.

2.1.1. Notice Qualifiers

 The ACPS Pointer qualifier contains a pointer to an Attribute
 Certification Practice Statement (ACPS) published by the AA.  The
 pointer is in the form of a URI.  Processing requirements for this
 qualifier are a local matter.

Francis & Pinkas Standards Track [Page 4] RFC 4476 AC Policies Extension May 2006

 The AC User Notice is intended for display to a relying party when an
 attribute certificate is used.  The application software SHOULD
 display the AC User Notice of the AC.  The AC User Notice is defined
 in [RFC3280].  It has two optional fields: the noticeRef field and
 the explicitText field.
    The noticeRef field, if used, names an organization and
    identifies, by number, a particular textual statement prepared by
    that organization.  For example, it might identify the
    organization's name and notice number 1.  In a typical
    implementation, the application software will have a notice file
    containing the current set of notices for the AA; the application
    will extract the notice text from the file and display it.
    Messages MAY be multilingual, allowing the software to select the
    particular language message for its own environment.
    An explicitText field includes the textual statement directly in
    the certificate.  The explicitText field is a string with a
    maximum size of 200 characters.
 If both the noticeRef and explicitText options are included in the
 one qualifier, and if the application software can locate the notice
 text indicated by the noticeRef option, then that text SHOULD be
 displayed; otherwise, the explicitText string SHOULD be displayed.

2.2. Attribute Certificate Policies

 The scope of this document is not the definition of the detailed
 content of ACPs themselves; therefore, specific policies are not
 defined in this document.

3. Security Considerations

 The ACP defined in this document applies for all the attributes that
 are included in one AC.  AAs SHALL ensure that the ACP applies to all
 the attributes that are included in the ACs they issue.
 Attributes may be dynamically grouped in several ACs.  It should be
 observed that since an AC may be issued under more than one ACP, the
 attributes included in a given AC MUST be compliant with all the ACPs
 from that AC.
 When verifying an AC, a relying party MUST determine that the AC was
 issued by a trusted AA and then that it has the appropriate policy.

Francis & Pinkas Standards Track [Page 5] RFC 4476 AC Policies Extension May 2006

 Failure of AAs to protect their private keys will permit an attacker
 to masquerade as them, potentially generating false ACs or revocation
 status.  Existence of bogus ACs and revocation status will undermine
 confidence in the system.  If the compromise is detected, then the
 certificate of the AA MUST be revoked.
 Rebuilding after such a compromise will be problematic, so AAs are
 advised to implement a combination of strong technical measures
 (e.g., tamper-resistant cryptographic modules) and appropriate
 management procedures (e.g., separation of duties) to avoid such an
 incident.
 Loss of an AA's private signing key may also be problematic.  The AA
 would not be able to produce revocation status or perform AC renewal
 (i.e., the issue of a new AC with the same set of attributes with the
 same values, for the same holder, from the same AA but with a
 different validity period).  AC issuers are advised to maintain
 secure backup for signing keys.  The security of the key backup
 procedures is a critical factor in avoiding key compromise.
 The availability and freshness of revocation status will affect the
 degree of assurance that should be placed in a long-lived AC.  While
 long-lived ACs expire naturally, events may occur during an AC's
 natural lifetime that negate the binding between the AC holder and
 the attributes.  If revocation status is untimely or unavailable, the
 assurance associated with the binding is clearly reduced.
 The binding between an AC holder and attributes cannot be stronger
 than the cryptographic module implementation and algorithms used to
 generate the signature.  Short key lengths or weak hash algorithms
 will limit the utility of an AC.  AAs are encouraged to note advances
 in cryptology so they can employ strong cryptographic techniques.
 If an AC is tied to the holder's PKC using the baseCertificateID
 component of the Holder field and the PKI in use includes a rogue CA
 with the same issuer name specified in the baseCertificateID
 component, this rogue CA could issue a PKC to a malicious party,
 using the same issuer name and serial number as the proper holder's
 PKC.  Then the malicious party could use this PKC in conjunction with
 the AC.  This scenario SHOULD be avoided by properly managing and
 configuring the PKI so that there cannot be two CAs with the same
 name.  Another alternative is to tie ACs to PKCs using the
 publicKeyCert type in the ObjectDigestInfo field.  Failing this, AC
 verifiers have to establish (using other means) that the potential
 collisions cannot actually occur; for example, the Certificate Policy
 Statements (CPSs) of the CAs involved may make it clear that no such
 name collisions can occur.

Francis & Pinkas Standards Track [Page 6] RFC 4476 AC Policies Extension May 2006

 Implementers MUST ensure that following validation of an AC, only
 attributes that the issuer is trusted to issue are used in
 authorization decisions.  Other attributes, which MAY be present,
 MUST be ignored.  AC verifiers SHALL support means of being provided
 with this information.  The AA controls PKC extension (see [RFC3281])
 is one possibility, but it is optional to implement.  Configuration
 information is a likely alternative means, while out-of-band means is
 another.  This becomes very important if an AC verification
 application trusts more than one AC issuer.

4. IANA Considerations

 The AC policies extension is identified by an object identifier
 (OID).  The OID for the AC policies extension defined in this
 document was assigned from an arc delegated by the IANA to the PKIX
 Working Group.
 No further action by the IANA is necessary for this document.

5. References

5.1. Normative References

 [X.660|ISO9834-1] ITU-T Recommendation X.660 (1992) | ISO/IEC 9834-1:
                   1993, Information technology - Open Systems
                   Interconnection Procedures for the operation of OSI
                   Registration Authorities: General procedures.
 [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
                   Requirement Levels", BCP 14, RFC 2119, March 1997.
 [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.
 [RFC3281]         Farrell, S. and R. Housley, "An Internet Attribute
                   Certificate Profile for Authorization", RFC 3281,
                   April 2002.
 [ASN1]            X.680 - X.693 | ISO/IEC 8824: 1-4 Abstract Syntax
                   Notation One (ASN.1).

Francis & Pinkas Standards Track [Page 7] RFC 4476 AC Policies Extension May 2006

5.2. Informative Reference

 [X.509]           ITU-T Recommendation X.509 (2000): Information
                   Technology Open Systems Interconnections - The
                   Directory:  Public-key and Attribute Frameworks,
                   March 2000.

Francis & Pinkas Standards Track [Page 8] RFC 4476 AC Policies Extension May 2006

Appendix A. ASN.1 Definitions

 This appendix is normative.

ASN.1 Module

AcPolicies { iso(1) identified-organization(3) dod(6)

   internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
   id-mod-ac-policies(26) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

– EXPORTS ALL –

IMPORTS

– Imports from RFC 3280 [RFC3280], Appendix A

     UserNotice
        FROM PKIX1Implicit88 { iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) pkix(7)
        id-mod(0) 19 }
     id-pkix, id-pe
        FROM PKIX1Explicit88 { iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) pkix(7)
        id-mod(0) 18 };

– Locally defined OIDs

  1. - policyQualifierIds for Internet policy qualifiers
 id-qt                    OBJECT IDENTIFIER ::=  { id-pkix 2 }
 id-qt-acps               OBJECT IDENTIFIER ::=  { id-qt 4 }
 id-qt-acunotice          OBJECT IDENTIFIER ::=  { id-qt 5 }

– Attributes

 id-pe-acPolicies         OBJECT IDENTIFIER ::= { id-pe 15 }
 AcPoliciesSyntax ::=     SEQUENCE SIZE (1..MAX) OF PolicyInformation
 PolicyInformation ::=    SEQUENCE {
    policyIdentifier         AcPolicyId,
    policyQualifiers         SEQUENCE SIZE (1..MAX) OF
                             PolicyQualifierInfo OPTIONAL }

Francis & Pinkas Standards Track [Page 9] RFC 4476 AC Policies Extension May 2006

 AcPolicyId ::=           OBJECT IDENTIFIER
 PolicyQualifierInfo ::=  SEQUENCE {
    policyQualifierId        PolicyQualifierId,
    qualifier                ANY DEFINED BY policyQualifierId }
 PolicyQualifierId ::=
    OBJECT IDENTIFIER               ( id-qt-acps | id-qt-acunotice )
 -- ACPS pointer qualifier
 ACPSuri ::=         IA5String
 -- ACP statement user notice qualifier
 ACUserNotice ::=    UserNotice
 -- UserNotice is defined in [RFC3280]

END

Authors' Addresses

 Christopher S. Francis
 Raytheon
 1501 72nd Street North, MS 25
 St. Petersburg, Florida  33764
 EMail: Chris_S_Francis@Raytheon.com
 Denis Pinkas
 Bull
 Rue Jean Jaures
 78340 Les Clayes-sous-Bois
 FRANCE
 EMail: Denis.Pinkas@bull.net

Francis & Pinkas Standards Track [Page 10] RFC 4476 AC Policies Extension May 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 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 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.

Acknowledgement

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

Francis & Pinkas Standards Track [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4476.txt · Last modified: 2006/05/03 18:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki