< draft-ietf-pkix-ac509prof-04.txt   draft-ietf-pkix-ac509prof-05.txt >
PKIX Working Group S. Farrell PKIX Working Group S. Farrell
INTERNET-DRAFT Baltimore Technologies INTERNET-DRAFT Baltimore Technologies
Expires in six months R. Housley Expires in six months R. Housley
SPYRUS SPYRUS
14 July 2000 8 August 2000
An Internet Attribute Certificate An Internet Attribute Certificate
Profile for Authorization Profile for Authorization
<draft-ietf-pkix-ac509prof-04.txt> <draft-ietf-pkix-ac509prof-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
skipping to change at page 3, line 10 skipping to change at page 3, line 10
Author's Addresses.............................................32 Author's Addresses.............................................32
Full Copyright Statement.......................................32 Full Copyright Statement.......................................32
Appendix A: Object Identifiers.................................33 Appendix A: Object Identifiers.................................33
Appendix B: ASN.1 Module.......................................34 Appendix B: ASN.1 Module.......................................34
1. Introduction 1. Introduction
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC2119]. in this document are to be interpreted as described in [RFC2119].
X.509 public key certificates (PKCs) [X.509-97, X.509-2000, X.509 public key certificates (PKCs) [X.509-1997, X.509-2000,
PKIXPROF] bind an identity and a public key. An attribute PKIXPROF] bind an identity and a public key. An attribute
certificate (AC) is a structure similar to a PKC; the main certificate (AC) is a structure similar to a PKC; the main
difference being that the AC contains no public key. An AC may difference being that the AC contains no public key. An AC may
contain attributes that specify group membership, role, security contain attributes that specify group membership, role, security
clearance, or other authorization information associated with the AC clearance, or other authorization information associated with the AC
holder. The syntax for the AC is defined in Recommendation X.509, holder. The syntax for the AC is defined in Recommendation X.509,
making the term "X.509 certificate" ambiguous. making the term "X.509 certificate" ambiguous.
Some people constantly confuse PKCs and ACs. An analogy may make the Some people constantly confuse PKCs and ACs. An analogy may make the
distinction clear. A PKC can be considered to be like a passport: it distinction clear. A PKC can be considered to be like a passport: it
skipping to change at page 5, line 47 skipping to change at page 5, line 47
| Lookup +--------------+ | Lookup | Lookup +--------------+ | Lookup
| | | | | | | |
+---------------+ Repository +---------+ +---------------+ Repository +---------+
| | | |
+--------------+ +--------------+
Figure 1: AC Exchanges Figure 1: AC Exchanges
1.3 Document Structure 1.3 Document Structure
The remainder of the document is structured as follows: Section 2 defines some terminology. Section 3 specifies the
requirements that this profile is intended to meet.; Section 4
Section 2 defines some terminology; Section 3 specifies the contains the profile of the X.509 AC. Section 5 specifies rules for
requirements that this profile is to meet; Section 4 contains the AC validation. Section 6 specifies rules for AC revocation checks.
profile of the X.509 AC; Section 5 specifies rules for AC Section 7 specifies optional features which MAY be supported;
validation; Section 6 specifies rules for AC revocation checks; however, support for these features is not required for conformance
Section 7 specifies optional features which MAY be supported but for to this profile. Finally, appendices contain the list of OIDs
which support is not required for conformance to this profile; and required to support this specification and an ASN.1 module.
Appendices contain the list of OIDs required to support this
specification and a ASN.1 module.
2. Terminology 2. Terminology
For simplicity, we use the terms client and server in this For simplicity, we use the terms client and server in this
specification. This is not intended to indicate that ACs are only to specification. This is not intended to indicate that ACs are only to
be used in client-server environments. For example, ACs may be used be used in client-server environments. For example, ACs may be used
in the S/MIME v3 context, where the mail user agent would be both a in the S/MIME v3 context, where the mail user agent would be both a
"client" and a "server" in the sense the terms are used here. "client" and a "server" in the sense the terms are used here.
Term Meaning Term Meaning
skipping to change at page 6, line 28 skipping to change at page 6, line 28
AC Attribute Certificate AC Attribute Certificate
AC user any entity that parses or processes an AC AC user any entity that parses or processes an AC
AC verifier any entity that checks the validity of an AC and AC verifier any entity that checks the validity of an AC and
then makes use of the result then makes use of the result
AC issuer the entity which signs the AC, synonymous in this AC issuer the entity which signs the AC, synonymous in this
specification with "AA" specification with "AA"
AC holder the entity indicated (perhaps indirectly) in the AC holder the entity indicated (perhaps indirectly) in the
holder field of the AC holder field of the AC
Client the entity which is requesting the action for Client the entity which is requesting the action for
which authorization checks are to be made which authorization checks are to be made
Proxying In this specification, Proxying is used to mean Proxying in this specification, Proxying is used to mean
the situation where an application server acts as the situation where an application server acts as
an application client on behalf of a user. an application client on behalf of a user.
Proxying here does not mean granting of authority. Proxying here does not mean granting of authority.
PKC Public Key Certificate - uses the type ASN.1 PKC Public Key Certificate - uses the type ASN.1
Certificate defined in X.509 and profiled in RFC Certificate defined in X.509 and profiled in RFC
2459. This (non-standard) acronym is used in order 2459. This (non-standard) acronym is used in order
to avoid confusion about the term "X.509 to avoid confusion about the term "X.509
certificate". certificate".
Server the entity which requires that the authorization Server the entity which requires that the authorization
checks are made checks are made
3. Requirements 3. Requirements
This AC profile meets the following requirements. This AC profile meets the following requirements.
Time/Validity requirements: Time/Validity requirements:
1. Support for short-lived as well as long-lived ACs is required. 1. Support for short-lived as well as long-lived ACs. Typical
Typical short-lived validity periods might be measured in short-lived validity periods might be measured in hours, as
hours, as opposed to months for PKCs. Short validity periods opposed to months for PKCs. Short validity periods allow ACs to
allow ACs to be useful without a revocation mechanism. be useful without a revocation mechanism.
Attribute Types: Attribute Types:
2. Issuers of ACs should be able to define their own attribute 2. Issuers of ACs should be able to define their own attribute
types for use within closed domains. types for use within closed domains.
3. Some standard attribute types should be defined which can be 3. Some standard attribute types should be defined which can be
contained within ACs. Examples include "access identity", contained within ACs. Examples include "access identity,"
"group", "role", "clearance", "audit identity", and "charging "group," "role," "clearance," "audit identity," and "charging
id". identity."
4. Standard attribute types should be defined in a manner that 4. Standard attribute types should be defined in a manner that
permits an AC verifier to distinguish between uses of the same permits an AC verifier to distinguish between uses of the same
attribute in different domains. For example, the attribute in different domains. For example, the
"Administrators group" as defined by Baltimore and the "Administrators group" as defined by Baltimore and the
"Administrators group" as defined by SPYRUS should be easily "Administrators group" as defined by SPYRUS should be easily
distinguished. distinguished.
Targeting of ACs: Targeting of ACs:
5. It should be possible to "target" an AC at one, or a small 5. It should be possible to "target" an AC at one, or a small
skipping to change at page 10, line 19 skipping to change at page 10, line 19
type AttributeType, type AttributeType,
values SET OF AttributeValue values SET OF AttributeValue
-- at least one value is required -- at least one value is required
} }
AttributeType ::= OBJECT IDENTIFIER AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType AttributeValue ::= ANY DEFINED BY AttributeType
Implementers should note that the DER encoding (see [X.509- Implementers should note that the DER encoding (see [X.509-
88],[X.208-88]) of the SET OF values requires ordering of the 1988],[X.208-1988]) of the SET OF values requires ordering of the
encodings of the values. Though this issue arises with respect to encodings of the values. Though this issue arises with respect to
distinguished names, and has to be handled by [PKIXPROF] distinguished names, and has to be handled by [PKIXPROF]
implementations, its is much more significant in this context, since implementations, its is much more significant in this context, since
the inclusion of multiple values is much more common in ACs. the inclusion of multiple values is much more common in ACs.
4.2 Profile of Standard Fields 4.2 Profile of Standard Fields
For all GeneralName fields in this profile the otherName (except as For all GeneralName fields in this profile the otherName (except as
noted below), x400Address, ediPartyName and registeredID options noted below), x400Address, ediPartyName and registeredID options
MUST NOT be used. The use of Kerberos [KRB] principal names, MUST NOT be used. The use of Kerberos [KRB] principal names,
skipping to change at page 12, line 9 skipping to change at page 12, line 9
that the AC issuer does not have to know which PKC the AC verifier that the AC issuer does not have to know which PKC the AC verifier
will use for it (the AC issuer). Using the baseCertificateID field will use for it (the AC issuer). Using the baseCertificateID field
to reference the AC issuer would mean that the AC verifier would to reference the AC issuer would mean that the AC verifier would
have to trust the PKC that the AC issuer chose (for itself) at AC have to trust the PKC that the AC issuer chose (for itself) at AC
creation time. creation time.
4.2.4 Signature 4.2.4 Signature
Contains the algorithm identifier used to validate the AC signature. Contains the algorithm identifier used to validate the AC signature.
This MUST be one of the following algorithms defined in [PKIXPROF] This MUST be one of the signing algorithms defined in [PKIXALGS].
section 7.2: md5WithRSAEncryption, id-dsa-with-sha1 or sha-
1WithRSAEncryption..
id-dsa-with-sha1 MUST be supported by all AC users. The other id-dsa-with-sha1 MUST be supported by all AC users. The other
algorithms SHOULD be supported. algorithms MAY be supported.
4.2.5 Serial Number 4.2.5 Serial Number
For any conforming AC, the issuer/serialNumber pair MUST form a For any conforming AC, the issuer/serialNumber pair MUST form a
unique combination, even if ACs are very short-lived. unique combination, even if ACs are very short-lived.
AC issuers MUST force the serialNumber to be a positive integer, AC issuers MUST force the serialNumber to be a positive integer,
that is, the sign bit in the DER encoding of the INTEGER value MUST that is, the sign bit in the DER encoding of the INTEGER value MUST
be zero - this can be done by adding a leading (leftmost) '00'H be zero - this can be done by adding a leading (leftmost) '00'H
octet if necessary. This removes a potential ambiguity in mapping octet if necessary. This removes a potential ambiguity in mapping
skipping to change at page 13, line 41 skipping to change at page 13, line 39
states that this field SHOULD NOT be used by conforming CAs, but states that this field SHOULD NOT be used by conforming CAs, but
that applications SHOULD be able to parse PKCs containing the field. that applications SHOULD be able to parse PKCs containing the field.
4.2.9 Extensions 4.2.9 Extensions
The extensions field generally gives information about the AC as The extensions field generally gives information about the AC as
opposed to information about the AC holder. opposed to information about the AC holder.
An AC that has no extensions conforms to the profile; however, An AC that has no extensions conforms to the profile; however,
section 4.3 defines the extensions that MAY be used with this section 4.3 defines the extensions that MAY be used with this
profile, and whether or not they may be marked criticial. If any profile, and whether or not they may be marked critical. If any
other critical extension is used, then the AC does not conform to other critical extension is used, then the AC does not conform to
this profile. However, if any other non-critical extension is used, this profile. However, if any other non-critical extension is used,
then the AC does conform to this profile. then the AC does conform to this profile.
The extensions defined for ACs provide methods for associating The extensions defined for ACs provide methods for associating
additional attributes with holders. This profile also allows additional attributes with holders. This profile also allows
communities to define private extensions to carry information unique communities to define private extensions to carry information unique
to those communities. Each extension in an AC may be designated as to those communities. Each extension in an AC may be designated as
critical or non-critical. An AC using system MUST reject an AC if critical or non-critical. An AC using system MUST reject an AC if
it encounters a critical extension it does not recognize; however, a it encounters a critical extension it does not recognize; however, a
skipping to change at page 15, line 7 skipping to change at page 15, line 7
The value of an audit identity MUST be longer than zero octets. The The value of an audit identity MUST be longer than zero octets. The
value of an audit identity MUST NOT be longer than 20 octets. value of an audit identity MUST NOT be longer than 20 octets.
name id-pe-ac-auditIdentity name id-pe-ac-auditIdentity
OID { id-pe 4 } OID { id-pe 4 }
syntax OCTET STRING syntax OCTET STRING
criticality MUST be TRUE criticality MUST be TRUE
4.3.2 AC Targeting 4.3.2 AC Targeting
To target an AC , the target information extension, imported from To target an AC, the target information extension, imported from
[X.509-2000], MAY be used to specify a number of servers/services. [X.509-2000], MAY be used to specify a number of servers/services.
The intent is that the AC SHOULD only be usable at the specified The intent is that the AC SHOULD only be usable at the specified
servers/services. An (honest) AC verifier who is not amongst the servers/services. An (honest) AC verifier who is not amongst the
named servers/services MUST reject the AC. named servers/services MUST reject the AC.
If this extension is not present, then the AC is not targeted and If this extension is not present, then the AC is not targeted and
may be accepted by any server. may be accepted by any server.
In this profile, the targeting information simply consists of a list In this profile, the targeting information simply consists of a list
of named targets or groups. of named targets or groups.
skipping to change at page 16, line 43 skipping to change at page 16, line 43
MAY be used to assist the AC verifier in checking the revocation MAY be used to assist the AC verifier in checking the revocation
status of the AC. Support for the id-ad-caIssuers accessMethod is status of the AC. Support for the id-ad-caIssuers accessMethod is
NOT REQUIRED by this profile since AC chains are not expected. NOT REQUIRED by this profile since AC chains are not expected.
The following accessMethod is used to indicate that revocation The following accessMethod is used to indicate that revocation
status checking is provided for this AC, using the OCSP protocol status checking is provided for this AC, using the OCSP protocol
defined in [OCSP]: defined in [OCSP]:
id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 } id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }
The accessLocation MUST contain a URI, and theURI MUST contain an The accessLocation MUST contain a URI, and the URI MUST contain an
HTTP URL [URL] that specifies the location of an OCSP responder. The HTTP URL [URL] that specifies the location of an OCSP responder. The
AC issuer MUST, of course, maintain an OCSP responder at this AC issuer MUST, of course, maintain an OCSP responder at this
location. location.
name id-ce-authorityInfoAccess name id-ce-authorityInfoAccess
OID { id-pe 1 } OID { id-pe 1 }
syntax AuthorityInfoAccessSyntax syntax AuthorityInfoAccessSyntax
criticality MUST be FALSE criticality MUST be FALSE
4.3.5 CRL Distribution Points 4.3.5 CRL Distribution Points
skipping to change at page 18, line 27 skipping to change at page 18, line 27
AttributeValue, the AttributeType still only occurs once, as AttributeValue, the AttributeType still only occurs once, as
specified in section 4.2.7. specified in section 4.2.7.
4.4.1 Service Authentication Information 4.4.1 Service Authentication Information
The SvceAuthInfo attribute identifies the AC holder to the The SvceAuthInfo attribute identifies the AC holder to the
server/service by a name, and the attribute MAY include optional server/service by a name, and the attribute MAY include optional
service specific authentication information. Typically this will service specific authentication information. Typically this will
contain a username/password pair for a "legacy" application. contain a username/password pair for a "legacy" application.
This attribute is intended to be used to provide information that This attribute provides information that can be presented by the AC
can be presented by the AC verifier to be interpreted and verifier to be interpreted and authenticated by a separate
authenticated by a separate application within the target system. application within the target system. Note that this is a different
Note that this is a different use to that intended for the use to that intended for the accessIdentity attribute in 4.4.2
accessIdentity attribute in 4.4.2 below. below.
This attribute type will typically be encrypted when the authInfo This attribute type will typically be encrypted when the authInfo
field contains sensitive information, such as a password. field contains sensitive information, such as a password.
name id-aca-authenticationInfo name id-aca-authenticationInfo
OID { id-aca 1 } OID { id-aca 1 }
Syntax SvceAuthInfo Syntax SvceAuthInfo
values: Multiple allowed values: Multiple allowed
SvceAuthInfo ::= SEQUENCE { SvceAuthInfo ::= SEQUENCE {
skipping to change at page 19, line 55 skipping to change at page 19, line 55
roleName [1] GeneralName roleName [1] GeneralName
} }
The roleAuthority field MAY be used to specify the issuing authority The roleAuthority field MAY be used to specify the issuing authority
for the role specification certificate. There is no requirement that for the role specification certificate. There is no requirement that
a role specification certificate necessarily exists for the a role specification certificate necessarily exists for the
roleAuthority. This differs from [X.500-2000], where the roleAuthority. This differs from [X.500-2000], where the
roleAuthority field is assumed to name the issuer of a role roleAuthority field is assumed to name the issuer of a role
specification certificate. For example, to distinguish the specification certificate. For example, to distinguish the
administrator role as defined by "Baltimore" from that defined by administrator role as defined by "Baltimore" from that defined by
"Spyrus", one could put the value "administrator" in the roleName "SPYRUS", one could put the value "administrator" in the roleName
field and the value "Baltimore" or "Spyrus" in the roleAuthority field and the value "Baltimore" or "SPYRUS" in the roleAuthority
field. field.
The roleName field MUST be present, and roleName MUST use the The roleName field MUST be present, and roleName MUST use the
uniformResourceIdentifier CHOICE of the GeneralName. uniformResourceIdentifier CHOICE of the GeneralName.
name id-at-role name id-at-role
OID { id-at 72 } OID { id-at 72 }
syntax RoleSyntax syntax RoleSyntax
values: Multiple allowed values: Multiple allowed
4.4.6 Clearance 4.4.6 Clearance
The clearance attribute, specified in [X.501-93], carries clearance The clearance attribute, specified in [X.501-1993], carries
(associated with security labeling) information about the AC holder. clearance (associated with security labeling) information about the
AC holder.
The policyId field is used to identify the security policy to which The policyId field is used to identify the security policy to which
the clearance relates. The policyId indicates the semantics of the the clearance relates. The policyId indicates the semantics of the
classList and securityCategories fields. classList and securityCategories fields.
This specification includes the classList field exactly as is This specification includes the classList field exactly as is
specified in [X.501-93]. Additional security classification values, specified in [X.501-1993]. Additional security classification
and their position in the classification hierarchy, may be defined values, and their position in the classification hierarchy, may be
by a security policy as a local matter or by bilateral agreement. defined by a security policy as a local matter or by bilateral
The basic security classification hierarchy is, in ascending order: agreement. The basic security classification hierarchy is, in
unmarked, unclassified, restricted, confidential, secret, and top- ascending order: unmarked, unclassified, restricted, confidential,
secret. secret, and top-secret.
An organization can develop its own security policy that defines An organization can develop its own security policy that defines
security classification values and their meanings. However, the BIT security classification values and their meanings. However, the BIT
STRING positions 0 through 5 are reserved for the basic security STRING positions 0 through 5 are reserved for the basic security
classification hierarchy. classification hierarchy.
If present, the SecurityCategory field provides further If present, the SecurityCategory field provides further
authorization information. The security policy identified by the authorization information. The security policy identified by the
policyId field indicates the syntaxes that are allowed to be present policyId field indicates the syntaxes that are allowed to be present
in the securityCategories SET. An OBJECT IDENTIFIER identifies each in the securityCategories SET. An OBJECT IDENTIFIER identifies each
skipping to change at page 21, line 29 skipping to change at page 21, line 30
-- --
-- SECURITY-CATEGORY MACRO ::= -- SECURITY-CATEGORY MACRO ::=
-- BEGIN -- BEGIN
-- TYPE NOTATION ::= type | empty -- TYPE NOTATION ::= type | empty
-- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
-- END -- END
name { id-at-clearance } name { id-at-clearance }
OID { joint-iso-ccitt(2) ds(5) module(1) OID { joint-iso-ccitt(2) ds(5) module(1)
selected-attribute-types(5) clearance (55) } selected-attribute-types(5) clearance (55) }
syntax Clearance - imported from [X.501-93] syntax Clearance - imported from [X.501-1993]
values Multiple allowed values Multiple allowed
4.5 Profile of AC issuer's PKC 4.5 Profile of AC issuer's PKC
The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
extension in the PKC MUST NOT explicitly indicate that the AC extension in the PKC MUST NOT explicitly indicate that the AC
issuer's public key cannot be used to validate a digital signature. issuer's public key cannot be used to validate a digital signature.
In order to avoid confusion regarding serial numbers and In order to avoid confusion regarding serial numbers and
revocations, an AC issuer MUST NOT also be a PKC Issuer. That is, revocations, 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 an AC issuer cannot be a CA as well. So, the AC issuer's PKC MUST
skipping to change at page 22, line 31 skipping to change at page 22, line 31
AC validity. If the evaluation time is equal to either AC validity. If the evaluation time is equal to either
notBeforeTime or notAfterTime, then the AC is timely and this notBeforeTime or notAfterTime, then the AC is timely and this
check succeeds. Note that in some applications, the evaluation check succeeds. Note that in some applications, the evaluation
time MAY not be the same as the current time. time MAY not be the same as the current time.
5. The AC targeting check MUST pass as specified in section 4.3.2. 5. The AC targeting check MUST pass as specified in section 4.3.2.
6. If the AC contains an unsupported critical extension, then the 6. If the AC contains an unsupported critical extension, then the
AC MUST be rejected. AC MUST be rejected.
Support for an extension in this context means: Support for an extension in this context means:
1. The AC verifier MUST be able to parse the extension value. 1. The AC verifier MUST be able to parse the extension value.
2. Where the extension value SHOULD cause the AC to be rejected, 2. Where the extension value SHOULD cause the AC to be rejected,
the AC verifier MUST reject the AC. the AC verifier MUST reject the AC.
Additional Checks: Additional Checks:
1. The AC MAY be rejected on the basis of further AC verifier 1. The AC MAY be rejected on the basis of further AC verifier
configuration. For example, an AC verifier may be configured to configuration. For example, an AC verifier may be configured to
reject ACs which contain or lack certain attributes. reject ACs which contain or lack certain attributes.
2. If the AC verifier provides an interface that allows 2. If the AC verifier provides an interface that allows
applications to query the contents of the AC, then the AC applications to query the contents of the AC, then the AC
verifier MAY filter the attributes from the AC on the basis of verifier MAY filter the attributes from the AC on the basis of
configured information. For example, an AC verifier might be configured information. For example, an AC verifier might be
skipping to change at page 25, line 50 skipping to change at page 25, line 50
AC holder, the server MAY need to proxy an AC. Such proxying MAY AC holder, the server MAY need to proxy an AC. Such proxying MAY
have to be done under the AC issuer's control, so that not every AC have to be done under the AC issuer's control, so that not every AC
is proxiable and so that a given proxiable AC can be proxied in a is proxiable and so that a given proxiable AC can be proxied in a
targeted fashion. Support for chains of proxies (with more than one targeted fashion. Support for chains of proxies (with more than one
intermediate server) MAY also be required. Note that this does not intermediate server) MAY also be required. Note that this does not
involve a chain of ACs. involve a chain of ACs.
In order to meet this requirement we define another extension, In order to meet this requirement we define another extension,
ProxyInfo, similar to the targeting extension. ProxyInfo, similar to the targeting extension.
When this extension is present the AC verifier must check that the When this extension is present, the AC verifier must check that the
entity from which the AC was received was allowed to send it and entity from which the AC was received was allowed to send it and
that the AC is allowed to be used by this verifier. that the AC is allowed to be used by this verifier.
The proxying information consists of a set of proxy information, The proxying information consists of a set of proxy information,
each of which is a set of targeting information. If the verifier and each of which is a set of targeting information. If the verifier and
the sender of the AC are both named in the same proxy set then the the sender of the AC are both named in the same proxy set then the
AC can be accepted (the exact rule is given below). AC can be accepted (the exact rule is given below).
The effect is that the AC holder can send the AC to any valid target The effect is that the AC holder can send the AC to any valid target
which can then only proxy to targets which are in one of the same which can then only proxy to targets which are in one of the same
skipping to change at page 29, line 7 skipping to change at page 29, line 7
MUST be applied to the set of attributes following attribute MUST be applied to the set of attributes following attribute
decryption, and the id-aca-encAttrs type MUST also be checked. decryption, and the id-aca-encAttrs type MUST also be checked.
name id-pe-aaControls name id-pe-aaControls
OID { id-pe 6 } OID { id-pe 6 }
syntax AAControls syntax AAControls
criticality MAY be TRUE criticality MAY be TRUE
8. Security Considerations 8. Security Considerations
The protection afforded private keys is a critical factor in The protection afforded for private keys is a critical factor in
maintaining security. Failure of AC issuers to protect their maintaining security. Failure of AC issuers to protect their
private keys will permit an attacker to masquerade as them, private keys will permit an attacker to masquerade as them,
potentially generating false ACs or revocation status. Existence of potentially generating false ACs or revocation status. Existence of
bogus ACs and revocation status will undermine confidence in the bogus ACs and revocation status will undermine confidence in the
system. If the compromise is detected, all ACs issued by the AC system. If the compromise is detected, all ACs issued by the AC
issuer MUST be revoked. Rebuilding after such a compromise will be issuer MUST be revoked. Rebuilding after such a compromise will be
problematic, so AC issuers are advised to implement a combination of problematic, so AC issuers are advised to implement a combination of
strong technical measures (e.g., tamper-resistant cryptographic strong technical measures (e.g., tamper-resistant cryptographic
modules) and appropriate management procedures (e.g., separation of modules) and appropriate management procedures (e.g., separation of
duties) to avoid such an incident. duties) to avoid such an incident.
skipping to change at page 31, line 22 skipping to change at page 31, line 22
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC2634. RFC2634.
[KRB] Kohl, J., Neuman, C., "The Kerberos Network [KRB] Kohl, J., Neuman, C., "The Kerberos Network
Authentication Service (V5)", RFC 1510. Authentication Service (V5)", RFC 1510.
[LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol [LDAP] Wahl, M., et al., "Lightweight Directory Access Protocol
(v3)", RFC 2251. (v3)", RFC 2251.
[OCSP] Myers, M., et al., " X.509 Internet Public Key [OCSP] Myers, M., et al., " X.509 Internet Public Key
Infrastructure - Online Certificate Status Protocol - Infrastructure - Online Certificate Status Protocol -
OCSP", RFC 2560. OCSP", RFC 2560.
[PKIXALGS] Polk, T., Bassham, L., "Internet X.509 Public Key
Infrastructure Representation of Public Keys and Digital
Signatures in Internet X.509 Public Key Infrastructure
Certificates", draft-ietf-pkix-pkalgs-00.txt, work-in-
progress.
[PKINIT] Tung, B., et al., "Public Key Cryptography for Initial [PKINIT] Tung, B., et al., "Public Key Cryptography for Initial
Authentication in Kerberos", draft-ietf-cat-kerberos-pk- Authentication in Kerberos", draft-ietf-cat-kerberos-pk-
init-11.txt, work-in-progress. init-11.txt, work-in-progress.
[PKIXPROF] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet [PKIXPROF] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
Public Key Infrastructure - X.509 Certificate and CRL Public Key Infrastructure - X.509 Certificate and CRL
Profile", RFC 2459. Profile", draft-ietf-pkix-new-part1-02.txt, work-in-
progress.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP 9, October 1996. 3", RFC 2026, BCP 9, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119. Requirement Levels", RFC 2119.
[URL] Berners-Lee, T., Masinter L., and M. McCahill., "Uniform [URL] Berners-Lee, T., Masinter L., and M. McCahill., "Uniform
Resource Locators (URL)", RFC 1738. Resource Locators (URL)", RFC 1738.
[X.208-88] CCITT Recommendation X.208: Specification of Abstract [X.208-1988]CCITT Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT Recommendation X.209: Specification of Basic [X.209-88] CCITT Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1). Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988. 1988.
[X.501-88] CCITT Recommendation X.501: The Directory - Models. [X.501-88] CCITT Recommendation X.501: The Directory - Models.
1988. 1988.
[X.501-93] ITU-T Recommendation X.501 : Information Technology - [X.501-1993]ITU-T Recommendation X.501 : Information Technology -
Open Systems Interconnection - The Directory: Models, Open Systems Interconnection - The Directory: Models,
1993. 1993.
[X.509-88] CCITT Recommendation X.509: The Directory - [X.509-1988]CCITT Recommendation X.509: The Directory -
Authentication Framework. 1988. Authentication Framework. 1988.
[X.509-97] ITU-T Recommendation X.509: The Directory - [X.509-1997]ITU-T Recommendation X.509: The Directory -
Authentication Framework. 1997. Authentication Framework. 1997.
[X.509-2000]ITU-T Recommendation X.509: The Directory - Public-Key [X.509-2000]ITU-T Recommendation X.509: The Directory - Public-Key
and Attribute Certificate Frameworks. 2000 and Attribute Certificate Frameworks. 2000
Author's Addresses Author's Addresses
Stephen Farrell Stephen Farrell
Baltimore Technologies Baltimore Technologies
61/62 Fitzwilliam Lane 61/62 Fitzwilliam Lane
Dublin 2 Dublin 2
skipping to change at page 34, line 19 skipping to change at page 34, line 19
id-mod-attribute-cert(12)} id-mod-attribute-cert(12)}
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
IMPORTS IMPORTS
-- IMPORTed module OIDs MAY change if [PKIXPROF] changes
-- PKIX Certificate Extensions -- PKIX Certificate Extensions
Attribute, AlgorithmIdentifier, CertificateSerialNumber, Attribute, AlgorithmIdentifier, CertificateSerialNumber,
Extensions, UniqueIdentifier, Extensions, UniqueIdentifier,
id-pkix, id-pe, id-kp, id-ad, id-at id-pkix, id-pe, id-kp, id-ad, id-at
FROM PKIX1Explicit88 {iso(1) identified-organization(3) FROM PKIX1Explicit88 {iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) dod(6) internet(1) security(5) mechanisms(5)
pkix(7) id-mod(0) id-pkix1-explicit-88(1)} pkix(7) id-mod(0) id-pkix1-explicit-88(1)}
GeneralName, GeneralNames, id-ce GeneralName, GeneralNames, id-ce
FROM PKIX1Implicit88 {iso(1) identified-organization(3) FROM PKIX1Implicit88 {iso(1) identified-organization(3)
 End of changes. 28 change blocks. 
55 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/