doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4476.txt b/doc/rfc/rfc4476.txt
new file mode 100644
index 0000000..149b0ac
--- /dev/null
+++ b/doc/rfc/rfc4476.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+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 }
+
+   -- 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 )
+
+   -- 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
+
+    -- 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]
+