Transport Layer Security Working Group S. Farrell
INTERNET-DRAFT SSE
Expires Feb. 20, 1999. August 20, 1998
An Internet AttributeCertificate
Profile for Authorization
<draft-ietf-tls-ac509prof-00.txt>
Status of this memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
West Coast).
<<comments are contained in angle brackets like this>>
Abstract
Authorization support is required for various Internet
protocols, for example, TLS, CMS and their consumers,
and others. The X.509 AttributeCertificate provides a
structure which can form the basis for such services
[X.509]. This specification defines two profiles (a
simple one and a "full" one) for the use of X.509
AttributeCertificates to provide such authorization
services.
1. Introduction
The provision of authentication, data integrity and
confidentiality services for current Internet protocols
is well understood and many secure transports are defined
(e.g. TLS, IPSEC etc.). In many applications these
services are not sufficient (or too cumbersome to
administer) to provide the type of authorization services
required.
Farrell, S. Expires Feb. 20, 1999 [Page 1]
INTERNET-DRAFT AC PROF August 20 1998
AttributeCertificates (ACs) provide a method of
overcoming these problems. An AC is a structure which is
similar to an X.509 public key certificate with the main
difference being that it contains no public key. The AC
typically contains group membership, role, clearance and
other access control information associated with the AC
owner.
In conjunction with authentication services ACs provide
the means to securely transport authorization information
to applications.
The next section introduces some simple terminology. This
is followed a brief statement of requirements, then by
the definition of the "full" profile. The following
section describes an algorithm for AC validation. Next a
very limited, "simple" profile is defined and this is
followed by a description of security considerations
related to use of this specification. Appendices contain
sample ACs and a compilable ASN.1 module.
2. Terminology
Term Meaning
AC AttributeCertificate
AC user any entity that parses or processes an
AC
AC verifier any entity that checks the validity of
an AC and then makes use of the result
AC issuer the entity which signs the AC
AC owner the entity indicated (perhaps
indirectly) in the subject field of the
AC
Client the entity which is requesting the
action for which authorization checks
are to be made
PKC Public Key Certificate - uses the type
ASN.1 Certificate defined in X.509. This
(non-standard) acronym is used in order
to avoid confusion about the term "X.509
certificate".
Server the entity which requires that the
authorization checks are made
Farrell, S. Expires Feb. 20, 1999 [Page 2]
INTERNET-DRAFT AC PROF August 20 1998
3. Requirements
The following are the requirements which the "full"
profile defined here meets.
Time/Validity requirements:
1. Support for short-lived or long-lived ACs is
required. Typical validity periods might be measured in
hours, as opposed to months for X.509 certificates. Short
validity periods mean that ACs can be usable without
mandating a revocation scheme.
Attribute Types:
2. Issuers of ACs should be able to define their own
attribute types for use within closed domains.
3. Some standard attribute types should be defined
which can be contained within ACs, for example "access
identity", "group", "role", "clearance", "audit
identity", "charging id" etc.
4. Standard attribute types should be defined so that
it is possible for an AC verifier to distinguish between
e.g. the "Administrators group" as defined by SSE and the
"Administrators group" as defined by Widgets inc.
5. ACs should support the encryption of some, or all,
attributes (e.g. passwords for legacy applications). It
should be possible for such an encrypted attribute to be
deciphered by an appropriate AC verifier even where the
AC has not been received directly from the AC owner (i.e.
where the AC is delegated).
Targeting of ACs:
6. It should be possible to "target" an AC. This means
that a given AC may be "targeted" at one, or a number of,
servers/services in the sense that a trustworthy non-
target will reject the AC for authorization decisions.
Delegation:
7. It should be possible for a server to delegate an AC
when it acts as a client (for another server) on behalf
of the AC owner.
8. Delegation should be under the AC issuer's control,
so that not every AC is delegatable and so that a given
delegatable AC can be delegated in a targeted fashion.
9. Delegation should support chains of delegation where
more than one intermediate server is used.
Farrell, S. Expires Feb. 20, 1999 [Page 3]
INTERNET-DRAFT AC PROF August 20 1998
Push vs. Pull
10. ACs should be defined so that they can either be
"pushed" by the client to the server, or "pulled" by the
server from a network service (whether the AC issuer or a
directory service).
This profile specifically imposes no requirements for:
1. The meaning of a chain of ACs
2. AC revocation
3. AC translation
Support for such features may be part of some other
profile.
From this point in the document, the use of MUST, SHOULD
etc. is in conformance to [RFC2119]
4. The AC Profile
This section specifies the profile of the X.509 AC which
is to be supported by conforming implementations.
4.1 X.509 AttributeCertificate Definition
X.509 contains the definition of an AttributeCertificate
given below. Types which are not defined can be found in
[PKIX-1]
AttributeCertificate ::=
SIGNED AttributeCertificateInfo
AttributeCertificateInfo ::= SEQUENCE {
version Version DEFAULT v1,
subject CHOICE {
baseCertificateID [0] IssuerSerial,
subjectName [1] GeneralNames
},
issuer GeneralNames,
signature AlgortihmIdentifier,
serial CertificateSerialNumber,
validity AttrCertValidityPeriod,
attributes SEQUENCE OF Attribute,
issuerUID UniqueIdentifier OPTIONAL,
extensions Extensions OPTIONAL
}
Farrell, S. Expires Feb. 20, 1999 [Page 4]
INTERNET-DRAFT AC PROF August 20 1998
AttrCertValidityPeriod ::= SEQUENCE {
notBefore GeneralizedTime,
notAfter GeneralizedTime
}
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial INTEGER,
issuerUID UniqueIdentifier OPTIONAL
}
4.2 Object Identifiers
The following OIDs are used:
ietf-ac OBJECT IDENTIFIER ::= <<tbs>>
ietf-ac-extensions OBJECT IDENTIFIER ::= { ietf-ac 1}
ietf-ac-attributes OBJECT IDENTIFIER ::= { ietf-ac 2}
4.3 Profile of Standard Fields.
4.3.1 version
This must be the default value of v1, i.e. not present in
encoding.
4.3.2 subject
For any protocol where the AC is passed in an
authenticated message or session, and where the
authentication is based on the use of an X.509 public key
certificate (PKC), the subject field MUST use the
baseCertificateID.
With the baseCertificateID option, the subject's PKC
serialNumber and issuer MUST be identical to the AC
subject field. The PKC issuer MUST have a non-NULL X.500
name which is to be present as the single value of the of
the subject.issuerSerial.issuer construct in the
directoryName field. The subject.issuerSerial.issuerUID
field MUST only be used if the subject's PKC contains an
issuerUniqueID field.
The above means that the baseCertificateID is only usable
with PKC profiles (like PKIX) which mandate that the PKC
issuer field contain a value.
If the subject field uses the subjectName option then
only one name should be present.
Farrell, S. Expires Feb. 20, 1999 [Page 5]
INTERNET-DRAFT AC PROF August 20 1998
For all GeneralName fields in this profile the otherName,
x400Address, ediPartyName and registeredId options MUST
NOT be used
Any protocol which uses this profile SHOULD specify which
AC subject option is to be used and how this fits with
e.g. peer-entity authentication in the protocol.
4.3.3 issuer
ACs conforming to this profile MUST contain one and only
one GeneralName which must contain its value in the
directoryName field. This means that all AC issuers MUST
have non-NULL X.500 names.
4.3.4 validity
The validity field specifies the period for which the AC
issuer expects that the binding between the subject and
the attributes fields will be valid. There is no implied
guarantee that the binding will actually be valid at any
given moment during the validity period.
GeneralizedTime encoding is restricted as specified in
[PKIX-1] for the corresponding fields in a PKC.
Note that AC users MUST be able to handle the case where
an AC is issued, which (at the time of parsing), has its
entire validity period in the future (a "post-dated" AC).
This is valid for some applications, e.g. backup.
4.3.5 signature
Contains the algorithm identifier used to validate the AC
signature.
This MUST be one of:
algorithm OID
rsaWithSHA1 tbs - from PKIX/CMS
rsaWithMD5 tbs
dsaWithSHA1 tbs
dsaWithMD5 tbs
dsaWithSHA1 MUST be supported by all AC users. The other
algorithms SHOULD be supported.
Farrell, S. Expires Feb. 20, 1999 [Page 6]
INTERNET-DRAFT AC PROF August 20 1998
4.3.6 serial
For any given AC issuer, the issuer/serial pair MUST form
a unique combination, even if ACs are very short-lived
(one second is the shortest possible validity according
to the above).
AC issuers MUST force the serial number to be a positive
integer, that is, the topmost bit in the DER encoding of
the INTEGER value MUST NOT be a `1'B - this is done by
adding a leading (leftmost) `00'H octet if necessary.
This removes a potential ambiguity in mapping between an
string of octets and a serial number.
Given the uniqueness and timing requirements above serial
numbers can be expected to contain long integers, i.e. AC
users MUST be able to handle more than 32 bit integers
here.
There is no requirement that the serial numbers used by
any AC issuer follow any particular ordering, e.g. they
needn't be monotonically increasing with time.
4.3.7 attributes
The attributes field gives information about the AC
owner. When the AC is used for authorization this will
often contain a set of privileges. However, authorization
may also require support for "restrictions" - these are
not carried within the attributes field (though they
"belong" to the AC owner) but in the extensions field.
The attributes field contains a SET OF Attribute. For a
given AC each attribute type in the set MUST be unique,
that is, only one instance of each attribute type can
occur in a single AC. Each instance can however, be multi-
valued.
AC consumers MUST be able to handle multiple values for
all attribute types.
Standard attribute types are defined in section 4.5.
4.3.8 issuerUID
This field MUST NOT be used.
Farrell, S. Expires Feb. 20, 1999 [Page 7]
INTERNET-DRAFT AC PROF August 20 1998
4.3.9 extensions
The extensions field generally gives information about
the AC as opposed to information about the AC owner. The
exception is where restrictions are to be supported. If
one regards a restriction as a qualification on a
privilege then it is clear that restrictions must be
implemented as a critical extension.
Section 4.4 defines the extensions which MAY be used with
this profile. An AC which has no extensions conforms to
the profile. If any other critical extension is used,
then the AC does not conform to this profile. An AC which
contains additional non-critical extensions still
conforms.
4.4 Extensions.
4.4.1 Restrictions
A restriction is a "negative" privilege, for example an
AC may "state" that the AC owner is a member of the
administrative group except for purposes of backup.
Restrictions would more properly be implemented as a
separate field of the AC, but with the current version
can only be supported via the use of a critical
extension.
The value of this extension will be a SEQUENCE OF
Attribute. The rules stated above for the AC attributes
field (only one instance of each type etc.) apply here
also.
In addition an attribute type which occurs in the
attributes field MUST NOT occur in the restrictions field
(if present). This ensures that the entire AC contains
only one instance of any attribute type at the expense of
forcing the definition of new OIDs for some restrictions.
OID { ietf-ac-extensions 1 }
syntax SEQUENCE OF Attribute
criticality MUST be TRUE
4.4.2 Audit Identity
In some circumstances it is required (e.g. by data
protection/data privacy legislation) that audit trails do
not contain records which identify individuals. This
makes the use of the subject field of the AC unsuitable
for use in audit trails.
Farrell, S. Expires Feb. 20, 1999 [Page 8]
INTERNET-DRAFT AC PROF August 20 1998
In order to allow for such cases an AC MAY contain an
audit identity extension. Ideally it SHOULD be impossible
to derive the AC owner's identity from the audit identity
value.
The value of the audit identity plus the AC issuer/serial
should then be used for audit/logging purposes. If the
value of the audit identity is suitably chosen then a
server/service administrator can track the behaviour of
an AC owner without being able to identify the AC owner.
The server/service administrator in combination with the
AC issuer can presumably identify the AC owner in cases
where mis-behaviour is detected.
Of course, auditing could be based on the AC
issuer/serial pair, however, this method doesn't allow
tracking the same AC owner across different ACs. This
means that an audit identity is only useful if it lasts
for longer than the typical AC lifetime - how much longer
is an issue for the AC issuer implementation.
As the AC verifier might otherwise use the AC subject or
some other identifying value for audit purposes, this
extension MUST be critical when used.
Protocols which use ACs will often expose the identity of
the AC owner in the bits on-the-wire. In such cases, an
"opaque" audit identity does not make use of the AC
anonymous, it simply ensures that the ensuing audit
trails are "semi-anonymous".
OID { ietf-ac-extensions 3 }
syntax OCTET STRING
criticality must be TRUE
4.4.3 AC Targeting
In order to allow that an AC is "targeted" the delegation
information extension specifies a number of
servers/services. The intent is that the AC should only
be usable at these servers/services - an (honest) AC
verifier who is not amongst the named servers/services
MUST reject the AC.
This extension also controls delegation.
Farrell, S. Expires Feb. 20, 1999 [Page 9]
INTERNET-DRAFT AC PROF August 20 1998
If this extension is not present then the AC is not
delegatable. Any server which receives the AC such that
the subject and the authenticated peer-entity do not
match MUST reject the AC.
When this extension is present we are essentially
checking that the entity from which the AC was received
was allowed to send it and that the AC is allowed to be
used by this recipient.
The targeting information consists of the direct
information (targets field) and an optional set of
delegate information (delegates field). If the "direct
check" or any of the "delegate" checks (see below) pass
then the "targeting check" as a whole is successful.
Though the rules given below look complex, they aren't -
the effect is that the AC owner can send to any valid
target which can then only delegate to targets which are
in one of the same delegate sets as itself.
The following data structure is used to represent the
targeting/delegation information.
DelegationInfo ::= SEQUENCE {
owner CHOICE {
baseCertificateID [0] IssuerSerial,
subjectName [1] GeneralNames
},
targets Targets OPTIONAL,
delegates SEQUENCE OF Targets OPTIONAL
}
Targets ::= SEQUENCE OF Target
Target ::= CHOICE {
targetName [0] GeneralName,
targetGroup [1] GeneralName
}
We represent a special target, called "ALL" which is a
wildcard as a targetName with the OID choice and a value
of {ietf-ac-extensions 4 1}.
Farrell, S. Expires Feb. 20, 1999 [Page 10]
INTERNET-DRAFT AC PROF August 20 1998
The direct check passes if:
the identity of the client as established by the
underlying authentication service matches the owner
field
and
(
the targets field contains one targetName which
is the "ALL" value
or
the current server (recipient) is one of the
targetName fields in the targets part
or
the current server is a member of one of the
targetGroup fields in the targets part.
)
How the membership of a target within a targetGroup is
determined is not defined here. It is assumed that any
given target "knows" the names of the targetGroup's to
which it belongs or can otherwise determine its
membership.
A delegate check succeeds if
(
the identity of the sender as established by
the underlying authentication service matches
the owner field
and
(
the current server "matches" any one of
the delegate sets (where "matches" is as
for the direct check above)
)
)
or
(
the identity of the sender as established by
the underlying authentication service "matches"
one of the delegate sets (call it set "A")
and
(
the current server is one of the targetName
fields in the set "A"
or
the current server is a member of one of the
targetGroup fields in set "A".
)
)
Farrell, S. Expires Feb. 20, 1999 [Page 11]
INTERNET-DRAFT AC PROF August 20 1998
Where an AC is delegated more than once a number of
targets will be on the path from the original client
which is normally, but not always, the AC owner. In such
cases prevention of AC "stealing" requires that the AC
verifier MUST check that all targets on the path are
members of the same delegate set. It is the
responsibility of the AC using protocol to ensure that a
trustworthy list of targets on the path is available to
the AC verifier.
OID { ietf-ac-extensions 4 }
syntax DelegationInfo
criticality must be TRUE
4.4.4 authorityKeyIdentifier
The authorityKeyIdentifier extension as profiled in [PKIX-
1] MAY be used to assist the AC verifier in checking the
signature of the AC. The [PKIX-1] description should be
read as if "CA" meant "AC issuer". As with PKCs this
extension SHOULD be included in ACs.
OID { id-ce 35 }
syntax AuthorityKeyIdentifier
criticality MUST be FALSE
4.5 Attribute Types
<<it'd be much nicer to inherit all of the attribute
definitions instead of making new syntax - any suitable
candidates?>>
Some of the attribute types defined below make use of the
IetfAttrSyntax type 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 organisation)
allocates attribute values, but where multiple AC issuers
are deployed for performance, network or other reasons.
2.It allows the type of the attribute (privilege,
restriction) to be made explicit which helps server
implementations which provide an API on top of an AC
validation module.
3.The syntaxes allowed for values are restricted to
OCTET STRING and OID which reduces some of the matching
complexities associated with GeneralName.
Farrell, S. Expires Feb. 20, 1999 [Page 12]
INTERNET-DRAFT AC PROF August 20 1998
IetfAttrSyntax ::= SEQUENCE OF {
type INTEGER {
privilege(0),
restriction(1),
other(2)
}
DEFAULT privilege,
policyAuthority[0] GeneralNames OPTIONAL,
values SEQUENCE OF CHOICE {
octets OCTET STRING,
oid OBJECT IDENTIFIER
}
}
4.5.1 Service Authentication Info
This attribute type identifies the AC owner to the
server/service by a name and with optional authentication
information. Typically this will contain a
username/password pair for a "legacy" application (and
hence MAY need to be encrypted).
OID { ietf-ac-attributes 1}
Syntax SvceAuthInfo
values: Multiple allowed
SvceAuthInfo ::= SEQUENCE {
service GeneralName,
ident GeneralName,
authInfo OCTET STRING OPTIONAL
}
4.5.2 Access Identity
An access identity identifies the AC owner to the
server/service. For this attribute the authInfo field
MUST NOT be present.
OID { ietf-ac-attributes 2}
syntax SvceAuthInfo
values: Multiple allowed
4.5.3 Charging Identity
This attribute type identifies the AC owner for charging
purposes.
OID { ietf-ac-attributes 3}
syntax IetfAttrSyntax
values: Multiple allowed
Farrell, S. Expires Feb. 20, 1999 [Page 13]
INTERNET-DRAFT AC PROF August 20 1998
4.5.4 Group
This attribute carries information about group
memberships of the AC owner.
<<might be more useful to defined OS specific group
attribute types which map to UNIX gids or NT SIDs?>>
OID { ietf-ac-attributes 4}
syntax IetfAttrSyntax
values: Multiple allowed
4.5.5 Role
This attribute carries information about role allocations
of the AC owner.
OID { ietf-ac-attributes 5}
syntax IetfAttrSyntax
values: Multiple allowed
4.5.6 Clearance
This attribute carries clearance (security labelling)
information about the AC owner.
OID { id-aa-securityLabel }
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
syntax ESSSecurityLabel - imported from [ESS]
values Multiple allowed
4.5.7 EncryptedAttributes
Where an AC will be carried in clear within an
application protocol or where an AC which may be
delegated contains some sensitive information (e.g. a
legacy application username/password) then encryption of
AC attributes MAY be needed.
When a set of attributes are to be encrypted within an
AC, the cryptographic message syntax, EnvelopedData
structure [CMS] is used to carry the ciphertext(s) and
associated per-recipient keying information.
This type of attribute encryption is targeted which means
that before the AC is signed the attributes have been
encrypted for a set of predetermined recipients.
Farrell, S. Expires Feb. 20, 1999 [Page 14]
INTERNET-DRAFT AC PROF August 20 1998
The AC then contains the ciphertext(s) inside its signed
data.
The "enveloped-data" (id-envelopedData) ContentType is
used and the content field will contain the EnvelopedData
type.
Only one encrytpedAttributes attribute can be present in
an AC - however it MAY be multi-valued and each of its
values will contain an EnvelopedData.
Each value can contain a set of attributes (each possibly
a multi-valued attribute) encrypted for a set of
recipients.
The cleartext which is encrypted has the type:
ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName,
acSerial INTEGER,
attrs SEQUENCE OF Attribute
}
The DER encoding of the ACClearAttrs structure is used as
the encryptedContent field of the EnvelopedData, i.e. the
DER encoding MUST be embedded in an OCTET STRING.
The acIssuer and serial fields are present to prevent
ciphertext stealing - when an AC verifier has
successfully decrypted an encrypted attribute it MUST
then check that the AC issuer and serial fields contain
the same values. This prevents a malicious AC issuer from
copying ciphertext from another AC issuer's AC into an AC
issued by the malicious AC issuer.
The procedure for an AC issuer when encrypting attributes
is illustrated by the following (any other procedure
which gives the same result is fine):
1.Identify the sets of attributes which are to be
encrypted for each set of recipients.
2.For each attribute set which is to be encrypted:
2.1. Create an EnvelopedData structure for the data for
this set of recipients.
2.2. Encode the EnvelopedData as a value of the
EncryptedAttributes attribute
2.3. Ensure the cleartext attribute(s) are not present in
the to-be-signed AC
3.Add the EncryptedAttribute (with its multiple
values) to the AC
Farrell, S. Expires Feb. 20, 1999 [Page 15]
INTERNET-DRAFT AC PROF August 20 1998
OID { ietf-ac-attributes 6}
Syntax ContentInfo
values Multiple Allowed
5. AttributeCertificate Validation
This section describes a basic set of rules which 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. the time of evaluation MUST be within validity (if
the evaluation time is equal to either notBefore or
notAfter then the AC is timely, i.e. this check succeeds)
2. the signature must be valid - based on a PKC for the
AC issuer
3. the AC validity.notBefore must be within the
validity period of the AC issuer's PKC
4. if an AC contains attributes apparently encrypted
for the AC verifier then the decryption process MUST not
fail - if decryption fails then the AC MUST be rejected
5. the AC targeting check MUST pass (see section 4.4.3
above)
6. the AC issuer MUST be explicitly trusted - this is
NOT the same as the AC having a valid PKC - the AC
verifier will require some additional
configuration/parameterisation in order to determine this
7. if the AC contains any "unsupported" critical
extensions then the AC MUST be rejected.
"Support" for an extension in this context means:
1.the AC verifier MUST be able to parse the extension
value
2.where the extension value SHOULD cause the AC to be
rejected, the AC verifier MUST reject the AC
Additional Checks:
1.The AC MAY be rejected on the basis of further AC
verifier configuration, for example an AC verifier may be
configured to reject ACs which contain or lack certain
attribute types
2.If the AC verifier provides an interface which
allows applications to query the contents of the AC, then
the AC verifier MAY filter the attributes from the AC on
the basis of configured information, e.g. an AC verifier
might be configured not to return certain attributes to
certain targets.
Farrell, S. Expires Feb. 20, 1999 [Page 16]
INTERNET-DRAFT AC PROF August 20 1998
6. Conformance
This specification defines two levels of conformance,
simple and full. For each level the actors involved must
meet different requirements. The intention is that
support for the simple level should allow for freely
interoperable but fairly inflexible and "featureless" AC
based authorization. Full conformance requires more
effort from implementors, may not be as widely
interoperable and is harder to administer, but does offer
much more flexibility and many more features.
A fully conformant AC issuer MUST be able to produce all
of the attribute types and extensions specified above. A
fully conformant AC verifier MUST "support" all of the
attribute types and extensions specified above. "Support"
in the previous sentence means more than just parsing -
it means that the AC verifier (which is part of a target)
MUST be able to reject any AC which should not be valid
at that target and MUST be able to make any attributes
and extensions which were not fully processed available
to the calling application.
A fully conformant AC issuer is responsible to ensure
that no AC produced could be accepted by a simply
conformant AV verifier in such a way as to cause a
security breach.
<<dunno if that can happen but I should think about it>>
Simple conformance for an AC issuer means support for
production of ACs which:
1.always use the baseCertificateID subject name
alternative
2.are never post-dated
3.can contain AccessIdentity, Group and/or Role
attributes with multiple values
4.do not contain any other attributes which cannot
safely be ignored by an AC verifier
5.can contain the AuthorityKeyIdentifier extension
6.contain no critical extensions (and hence is not
delegatable)
7.do not contain encrypted attributes
Simple conformance for an AC verifier means support for
the validation of ACs which are produced by simply
conformant AC issuers. A simply comformant AC verifier
can ignore the presence of any unsupported attributes or
Farrell, S. Expires Feb. 20, 1999 [Page 17]
INTERNET-DRAFT AC PROF August 20 1998
extensions (of course it must reject all ACs which
contain critical extensions) and need only make the
values of the above attributes available to applications.
7. Security Considerations
tbs
8. References
[CMS] Housley, R., "Cryptographic Message Syntax",
draft-ietf-smime-cms-05.txt, May 1998.
[ESS] Hoffman, P., "Enhanced Security Services for
S/MIME",
draft-ietf-smime-ess-05.txt, April 1998.
[PKIX-1] Housley, R., Ford, W., Polk, T, & Solo, D.,
"Internet Public Key Infrastructure - X.509
Certificate and CRL profile",
draft-ietf-pkix-ipki-part1-07.txt, March
1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, March
1997.
Author's Address
Stephen Farrell,
SSE Ltd.
Fitzwilliam Court,
Leeson Close,
Dublin 2,
IRELAND
tel: +353-1-676-9089
email: stephen.farrell@sse.ie
Appendix 1: Samples
tbs
Appendix 2: "Compilable" ASN.1 Module
tbs
Farrell, S. Expires Feb. 20, 1999 [Page 18]
