If the crlDistributionPoints extension is present, then exactly one   distribution point MUST be present.  The crlDistributionPoints   extension MUST use the DistributionPointName option, which MUST   contain a fullName, which MUST contain a single name form.  That name   MUST contain either a distinguished name or a URI.  The URI MUST be   either an HTTP URL or an LDAP URL [URL].      name           id-ce-cRLDistributionPoints      OID            { id-ce 31 }      syntax         CRLDistPointsSyntax      criticality    MUST be FALSE4.3.6   No Revocation Available   The noRevAvail extension, defined in [X.509-2000], allows an AC   issuer to indicate that no revocation information will be made   available for this AC.   This extension MUST be non-critical.  An AC verifier that does not   understand this extension might be able to find a revocation list   from the AC issuer, but the revocation list will never include an   entry for the AC.      name           id-ce-noRevAvail      OID            { id-ce 56 }      syntax         NULL (i.e. '0500'H is the DER encoding)      criticality    MUST be FALSE4.4 Attribute Types   Some of the attribute types defined below make use of the   IetfAttrSyntax type, also defined below.  The reasons for using this   type are:   1. It allows a separation between the AC issuer and the attribute      policy authority.  This is useful for situations where a single      policy authority (e.g. an organization) allocates attribute      values, but where multiple AC issuers are deployed for performance      or other reasons.   2. The syntaxes allowed for values are restricted to OCTET STRING,      OBJECT IDENTIFIER, and UTF8String, which significantly reduces the      complexity associated with matching more general syntaxes.  All      multi-valued attributes using this syntax are restricted so that      each value MUST use the same choice of value syntax.  For example,      AC issuers must not use one value with an oid and a second value      with a string.Farrell & Housley           Standards Track                    [Page 18]RFC 3281           An Internet Attribute Certificate          April 2002               IetfAttrSyntax ::= SEQUENCE {                    policyAuthority [0] GeneralNames    OPTIONAL,                    values          SEQUENCE OF CHOICE {                                  octets    OCTET STRING,                                  oid       OBJECT IDENTIFIER,                                  string    UTF8String                   }               }   In the descriptions below, each attribute type is either tagged   "Multiple Allowed" or "One Attribute value only; multiple values   within the IetfAttrSyntax".  This refers to the SET OF   AttributeValues; the AttributeType still only occurs once, as   specified in section 4.2.7.4.4.1   Service Authentication Information   The SvceAuthInfo attribute identifies the AC holder to the   server/service by a name, and the attribute MAY include optional   service specific authentication information.  Typically this will   contain a username/password pair for a "legacy" application.   This attribute provides information that can be presented by the AC   verifier to be interpreted and authenticated by a separate   application within the target system.  Note that this is a different   use to that intended for the accessIdentity attribute in 4.4.2 below.   This attribute type will typically be encrypted when the authInfo   field contains sensitive information, such as a password.      name      id-aca-authenticationInfo      OID       { id-aca 1 }      Syntax    SvceAuthInfo      values:   Multiple allowed           SvceAuthInfo ::=    SEQUENCE {                service   GeneralName,                ident     GeneralName,                authInfo  OCTET STRING OPTIONAL           }4.4.2   Access Identity   The accessIdentity attribute identifies the AC holder to the   server/service.  For this attribute the authInfo field MUST NOT be   present.Farrell & Housley           Standards Track                    [Page 19]RFC 3281           An Internet Attribute Certificate          April 2002   This attribute is intended to be used to provide information about   the AC holder, that can be used by the AC verifier (or a larger   system of which the AC verifier is a component) to authorize the   actions of the AC holder within the AC verifier's system.  Note that   this is a different use to that intended for the svceAuthInfo   attribute described in 4.4.1 above.      name      id-aca-accessIdentity      OID       { id-aca 2 }      syntax    SvceAuthInfo      values:   Multiple allowed4.4.3   Charging Identity   The chargingIdentity attribute identifies the AC holder for charging   purposes.  In general, the charging identity will be different from   other identities of the holder.  For example, the holder's company   may be charged for service.      name      id-aca-chargingIdentity      OID       { id-aca 3 }      syntax    IetfAttrSyntax      values:   One Attribute value only; multiple values within the                IetfAttrSyntax4.4.4   Group   The group attribute carries information about group memberships of   the AC holder.      name      id-aca-group      OID       { id-aca 4 }      syntax    IetfAttrSyntax      values:   One Attribute value only; multiple values within the                IetfAttrSyntax4.4.5   Role   The role attribute, specified in [X.509-2000], carries information   about role allocations of the AC holder.   The syntax used for this attribute is:         RoleSyntax ::= SEQUENCE {                 roleAuthority   [0] GeneralNames OPTIONAL,                 roleName        [1] GeneralName         }Farrell & Housley           Standards Track                    [Page 20]RFC 3281           An Internet Attribute Certificate          April 2002   The roleAuthority field MAY be used to specify the issuing authority   for the role specification certificate.  There is no requirement that   a role specification certificate necessarily exists for the   roleAuthority.  This differs from [X.500-2000], where the   roleAuthority field is assumed to name the issuer of a role   specification certificate.  For example, to distinguish the   administrator role as defined by "Baltimore" from that defined by   "SPYRUS", one could put the value "urn:administrator" in the roleName   field and the value "Baltimore" or "SPYRUS" in the roleAuthority   field.   The roleName field MUST be present, and roleName MUST use the   uniformResourceIdentifier CHOICE of the GeneralName.      name      id-at-role      OID       { id-at 72 }      syntax    RoleSyntax      values:   Multiple allowed4.4.6   Clearance   The clearance attribute, specified in [X.501-1993], carries clearance   (associated with security labeling) information about the AC holder.   The policyId field is used to identify the security policy to which   the clearance relates.  The policyId indicates the semantics of the   classList and securityCategories fields.   This specification includes the classList field exactly as it is   specified in [X.501-1993].  Additional security classification   values, and their position in the classification hierarchy, may be   defined by a security policy as a local matter or by bilateral   agreement.  The basic security classification hierarchy is, in   ascending order: unmarked, unclassified, restricted, confidential,   secret, and top-secret.   An organization can develop its own security policy that defines   security classification values and their meanings.  However, the BIT   STRING positions 0 through 5 are reserved for the basic security   classification hierarchy.   If present, the SecurityCategory field provides further authorization   information.  The security policy identified by the policyId field   indicates the syntaxes that are allowed to be present in the   securityCategories SET.  An OBJECT IDENTIFIER identifies each of the   allowed syntaxes.  When one of these syntaxes is present in the   securityCategories SET, the OBJECT IDENTIFIER associated with that   syntax is carried in the SecurityCategory.type field.Farrell & Housley           Standards Track                    [Page 21]RFC 3281           An Internet Attribute Certificate          April 2002            Clearance  ::=  SEQUENCE {                 policyId  [0] OBJECT IDENTIFIER,                 classList [1] ClassList DEFAULT {unclassified},                 securityCategories                           [2] SET OF SecurityCategory OPTIONAL            }            ClassList  ::=  BIT STRING {                 unmarked       (0),                 unclassified   (1),                 restricted     (2)                 confidential   (3),                 secret         (4),                 topSecret      (5)            }            SecurityCategory ::= SEQUENCE {                 type      [0]  IMPLICIT OBJECT IDENTIFIER,                 value     [1]  ANY DEFINED BY type            }            -- This is the same as the original syntax which was defined            -- using the MACRO construct, as follows:            -- SecurityCategory ::= SEQUENCE {            --      type      [0]  IMPLICIT SECURITY-CATEGORY,            --      value     [1]  ANY DEFINED BY type            -- }            --            -- SECURITY-CATEGORY MACRO  ::=            -- BEGIN            -- TYPE NOTATION ::= type | empty            -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)            -- END       name      { id-at-clearance }       OID       { joint-iso-ccitt(2) ds(5) module(1)                   selected-attribute-types(5) clearance (55) }       syntax    Clearance - imported from [X.501-1993]       values    Multiple allowed4.5 Profile of AC issuer's PKC   The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage   extension in the PKC MUST NOT explicitly indicate that the AC   issuer's public key cannot be used to validate a digital signature.   In order to avoid confusion regarding serial numbers and revocations,Farrell & Housley           Standards Track                    [Page 22]RFC 3281           An Internet Attribute Certificate          April 2002   an AC issuer MUST NOT also be a PKC Issuer.  That is, an AC issuer   cannot be a CA as well.  So, the AC issuer's PKC MUST NOT have a   basicConstraints extension with the cA BOOLEAN set to TRUE.5. Attribute Certificate Validation   This section describes a basic set of rules that all valid ACs MUST   satisfy.  Some additional checks are also described which AC   verifiers MAY choose to implement.   To be valid an AC MUST satisfy all of the following:   1. Where the holder uses a PKC to authenticate to the AC verifier,      the AC holder's PKC MUST be found, and the entire certification      path of that PKC MUST be verified in accordance with [PKIXPROF].      As noted in the security considerations section, if some other      authentication scheme is used, AC verifiers need to be very      careful mapping the identities (authenticated identity, holder      field) involved.   2. The AC signature must be cryptographically correct, and the AC      issuer's entire PKC certification path MUST be verified in      accordance with [PKIXPROF].   3. The AC issuer's PKC MUST also conform to the profile specified in      section 4.5 above.   4. The AC issuer MUST be directly trusted as an AC issuer (by      configuration or otherwise).   5. The time for which the AC is being evaluated MUST be within the AC      validity.  If the evaluation time is equal to either notBeforeTime      or notAfterTime, then the AC is timely and this check succeeds.      Note that in some applications, the evaluation time MAY not be the      same as the current time.   6. The AC targeting check MUST pass as specified in section 4.3.2.