< draft-ietf-pkix-ac509prof-05.txt   draft-ietf-pkix-ac509prof-06.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
8 August 2000 10th January 2001
An Internet Attribute Certificate An Internet Attribute Certificate
Profile for Authorization Profile for Authorization
<draft-ietf-pkix-ac509prof-05.txt> <draft-ietf-pkix-ac509prof-06.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 2, line 9 skipping to change at page 2, line 9
to establish a common baseline for generic applications requiring to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose broad interoperability as well as limited special purpose
requirements. The profile places emphasis on attribute certificate requirements. The profile places emphasis on attribute certificate
support for Internet electronic mail, IPSec, and WWW security support for Internet electronic mail, IPSec, and WWW security
applications. applications.
Table of Contents Table of Contents
Status of this Memo.............................................1 Status of this Memo.............................................1
Abstract........................................................1 Abstract........................................................1
Table of Contents...............................................1 Table of Contents...............................................2
1. Introduction.................................................3 1. Introduction.................................................3
1.1 Delegation and AC chains...............................4 1.1 Delegation and AC chains...............................4
1.2 Attribute Certificate Distribution ("push" vs. "pull").4 1.2 Attribute Certificate Distribution ("push" vs. "pull").4
1.3 Document Structure.....................................5 1.3 Document Structure.....................................5
2. Terminology..................................................6 2. Terminology..................................................6
3. Requirements.................................................7 3. Requirements.................................................7
4. Attribute Certificate Profile................................8 4. Attribute Certificate Profile................................8
4.1 X.509 Attribute Certificate Definition.................8 4.1 X.509 Attribute Certificate Definition.................8
4.2 Profile of Standard Fields............................10 4.2 Profile of Standard Fields............................10
4.2.1 Version.........................................10 4.2.1 Version.........................................10
4.2.2 Holder..........................................10 4.2.2 Holder..........................................10
4.2.3 Issuer..........................................11 4.2.3 Issuer..........................................11
4.2.4 Signature.......................................12 4.2.4 Signature.......................................12
4.2.5 Serial Number...................................12 4.2.5 Serial Number...................................12
4.2.6 Validity Period.................................12 4.2.6 Validity Period.................................12
4.2.7 Attributes......................................13 4.2.7 Attributes......................................13
4.2.8 Issuer Unique Identifier........................13 4.2.8 Issuer Unique Identifier........................13
4.2.9 Extensions......................................13 4.2.9 Extensions......................................13
4.3 Extensions............................................14 4.3 Extensions............................................13
4.3.1 Audit Identity..................................14 4.3.1 Audit Identity..................................14
4.3.2 AC Targeting....................................15 4.3.2 AC Targeting....................................15
4.3.3 Authority Key Identifier........................16 4.3.3 Authority Key Identifier........................16
4.3.4 Authority Information Access....................16 4.3.4 Authority Information Access....................16
4.3.5 CRL Distribution Points.........................17 4.3.5 CRL Distribution Points.........................17
4.3.6 No Revocation Available.........................17 4.3.6 No Revocation Available.........................17
4.4 Attribute Types.......................................17 4.4 Attribute Types.......................................17
4.4.1 Service Authentication Information..............18 4.4.1 Service Authentication Information..............18
4.4.2 Access Identity.................................18 4.4.2 Access Identity.................................18
4.4.3 Charging Identity...............................19 4.4.3 Charging Identity...............................19
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
skipping to change at page 10, line 41 skipping to change at page 10, line 41
krb5PrincipalName OID and the KerberosName syntax as defined in krb5PrincipalName OID and the KerberosName syntax as defined in
[PKINIT]. [PKINIT].
Conforming implementations MUST be able to support the dNSName, Conforming implementations MUST be able to support the dNSName,
directoryName, uniformResourceIdentifier, and iPAddress fields in directoryName, uniformResourceIdentifier, and iPAddress fields in
all cases where GeneralName is used. This is compatible with the all cases where GeneralName is used. This is compatible with the
GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7). GeneralName requirements in [PKIXPROF] (mainly in section 4.2.1.7).
4.2.1 Version 4.2.1 Version
The version field MUST be the default value of v1. That is, the The version field MUST be the (non-default) value of v2. That is,
version field is not present in the DER encoding, except when the the version field is present in the DER encoding.
holder is identified using the optional objectDigestInfo field, as
specified in section 7.3.
4.2.2 Holder 4.2.2 Holder
The Holder field is a SEQUENCE allowing three different (optional)
syntaxes: baseCertificateID, entityName and objectDigestInfo. Where
only one option is present the meaning of the Holder field is clear.
However, where more than one option is used, there is potential for
confusion as to which option is "normative", which is a "hint" etc.
Since the correct position is not clear from [X.509-2000] this
specification RECOMMENDS that only one of the options be used in any
given AC.
For any environment where the AC is passed in an authenticated For any environment where the AC is passed in an authenticated
message or session and where the authentication is based on the use message or session and where the authentication is based on the use
of an X.509 PKC, the holder field SHOULD use the baseCertificateID. of an X.509 PKC, the holder field SHOULD use the baseCertificateID.
With the baseCertificateID option, the holder's PKC serialNumber and With the baseCertificateID option, the holder's PKC serialNumber and
issuer MUST be identical to the AC holder field. The PKC issuer MUST issuer MUST be identical to the AC holder field. The PKC issuer MUST
have a non-empty distinguished name which is to be present as the have a non-empty distinguished name which is to be present as the
single value of the holder.baseCertificateID.issuer construct in the single value of the holder.baseCertificateID.issuer construct in the
directoryName field. The AC holder.baseCertificateID.issuerUID field directoryName field. The AC holder.baseCertificateID.issuerUID field
MUST only be used if the holder's PKC contains an issuerUniqueID MUST only be used if the holder's PKC contains an issuerUniqueID
skipping to change at page 11, line 16 skipping to change at page 11, line 23
present in both fields. Thus, the baseCertificateID is only usable present in both fields. Thus, the baseCertificateID is only usable
with PKC profiles (like [PKIXPROF]) which mandate that the PKC with PKC profiles (like [PKIXPROF]) which mandate that the PKC
issuer field contain a non-empty distinguished name value. issuer field contain a non-empty distinguished name value.
Note: An empty distinguished name is a distinguished name where the Note: An empty distinguished name is a distinguished name where the
SEQUENCE OF relative distinguished names is of zero length. In a DER SEQUENCE OF relative distinguished names is of zero length. In a DER
encoding this has the value '3000'H. encoding this has the value '3000'H.
If the holder field uses the entityName option and the underlying If the holder field uses the entityName option and the underlying
authentication is based on a PKC, then the entityName MUST be the authentication is based on a PKC, then the entityName MUST be the
same as the PKC subject field, unless the PKC subject field contains same as the PKC subject field or one of the values of the PKC
an empty distinguished name. If the PKC subject field contains an subjectAltName field extension (if present). Note that [PKIXPROF]
empty distinguished name, then the entityName field MUST be mandates that the subjectAltName extension be present if the PKC
identical to one of the values of the PKC subjectAltName field subject is an empty distinguished name. See the security
extension. Note that [PKIXPROF] mandates that the subjectAltNames consideration section which mentions some name collision problems
extension be present if the PKC subject is an empty distinguished that may arise when using the entityName option.
name. See the security consideration section which mentions some
name collision problems that may arise when using the entityName
option.
In any other case where the holder field uses the entityName option, In any other case where the holder field uses the entityName option,
then only one name SHOULD be present. then only one name SHOULD be present.
Implementations conforming to this profile are not required to Implementations conforming to this profile are not required to
support the use of the objectDigest field. However, section 7.3 support the use of the objectDigest field. However, section 7.3
specifies how this optional feature MAY be used. specifies how this optional feature MAY be used.
Any protocol conforming to this profile SHOULD specify which AC Any protocol conforming to this profile SHOULD specify which AC
holder option is to be used and how this fits with the supported holder option is to be used and how this fits with the supported
skipping to change at page 12, line 10 skipping to change at page 12, line 10
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 signing algorithms defined in [PKIXALGS]. This MUST be one of the signing algorithms defined in [PKIXALGS].
Conforming implementations MUST honor all MUST/SHOULD/MAY signing
id-dsa-with-sha1 MUST be supported by all AC users. The other algorithm statements specified in [PKIXALGS].
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 22, line 13 skipping to change at page 22, line 13
TRUE. TRUE.
5. Attribute Certificate Validation 5. Attribute Certificate Validation
This section describes a basic set of rules that all valid ACs MUST This section describes a basic set of rules that all valid ACs MUST
satisfy. Some additional checks are also described which AC satisfy. Some additional checks are also described which AC
verifiers MAY choose to implement. verifiers MAY choose to implement.
To be valid an AC MUST satisfy all of the following: To be valid an AC MUST satisfy all of the following:
1. The AC signature must be cryptographically correct, and the AC 1. Where the holder uses a PKC to authenticate to the AC verifier,
then 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 issuer's entire PKC certification path MUST be verified in
accordance with [PKIXPROF]. accordance with [PKIXPROF].
2. The AC issuer's PKC MUST also conform to the profile specified 3. The AC issuer's PKC MUST also conform to the profile specified
in section 4.5 above. in section 4.5 above.
3. The AC issuer MUST be directly trusted as an AC issuer (by 4. The AC issuer MUST be directly trusted as an AC issuer (by
configuration or otherwise). configuration or otherwise).
4. The time for which the AC is being evaluated MUST be within the 5. The time for which the AC is being evaluated MUST be within the
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. 6. The AC targeting check MUST pass as specified in section 4.3.2.
6. If the AC contains an unsupported critical extension, then the 7. 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:
skipping to change at page 29, line 54 skipping to change at page 29, line 54
space substrings, or leading and trailing white space. This space substrings, or leading and trailing white space. This
specification and [PKIXPROF] relaxes these requirements, requiring specification and [PKIXPROF] relaxes these requirements, requiring
support for binary comparison at a minimum. support for binary comparison at a minimum.
AC issuers MUST encode the distinguished name in the AC AC issuers MUST encode the distinguished name in the AC
holder.entityName field identically to the distinguished name in the holder.entityName field identically to the distinguished name in the
holder's PKC. If different encodings are used, implementations of holder's PKC. If different encodings are used, implementations of
this specification may fail to recognize that the AC and PKC belong this specification may fail to recognize that the AC and PKC belong
to the same entity. to the same entity.
If an attribute certificate 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 CPSs of
the CAs involved may make it clear that no such name collisions can
occur.
Implementers MUST ensure that following validation of an AC, only Implementers MUST ensure that following validation of an AC, only
attributes that the issuer is trusted to issue are used in attributes that the issuer is trusted to issue are used in
authorization decisions. Other attributes, which MAY be present MUST authorization decisions. Other attributes, which MAY be present MUST
be ignored. Given that the AA controls PKC extension is optional to be ignored. Given that the AA controls PKC extension is optional to
implement, AC verifiers MUST be provided with this information by implement, AC verifiers MUST be provided with this information by
other means. Configuration information is a likely alternative other means. Configuration information is a likely alternative
means. This becomes very important if an AC verifier trusts more means. This becomes very important if an AC verifier trusts more
than one AC issuer. than one AC issuer.
There is often a requirement to map between the authentication There is often a requirement to map between the authentication
supplied by a particular security protocol (e.g. TLS, S/MIME) and supplied by a particular security protocol (e.g. TLS, S/MIME) and
the AC holder's identity. If the authentication uses PKCs, then this the AC holder's identity. If the authentication uses PKCs, then this
mapping is straightforward. However, it is envisaged that ACs will mapping is straightforward. However, it is envisaged that ACs will
also be used in environments where the holder may be authenticated also be used in environments where the holder may be authenticated
using other means. Implementers SHOULD be very careful in mapping using other means. Implementers SHOULD be very careful in mapping
the authenticated identity to the AC holder. the authenticated identity to the AC holder.
9. References 9. References
[CMC] Myers, M., et al. "Certificate Management Messages over [CMC] Myers, M., et al. "Certificate Management Messages over
CMS", RFC2797. CMS", RFC2797.
[CMP] Adams, C., Farrell, S., "Internet X.509 Public Key [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key
Infrastructure - Certificate Management Protocols", Infrastructure - Certificate Management Protocols",
RFC2510. RFC2510.
[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 [PKIXALGS] Polk, T., Bassham, L., "Internet X.509 Public Key
Infrastructure Representation of Public Keys and Digital Infrastructure Representation of Public Keys and Digital
Signatures in Internet X.509 Public Key Infrastructure Signatures in Internet X.509 Public Key Infrastructure
Certificates", draft-ietf-pkix-pkalgs-00.txt, work-in- Certificates", draft-ietf-pkix-pkalgs-01.txt, work-in-
progress. 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-12.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", draft-ietf-pkix-new-part1-02.txt, work-in- Profile", draft-ietf-pkix-new-part1-03.txt, work-in-
progress. 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-1988]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-1993]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-1988]CCITT Recommendation X.509: The Directory - [X.509-1988]CCITT Recommendation X.509: The Directory -
Authentication Framework. 1988. Authentication Framework. 1988.
[X.509-1997]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 39/41 Parkgate Street
Dublin 2 Dublin 8
IRELAND IRELAND
tel: +353-1-647-3000 tel: +353-1-881-6000
email: stephen.farrell@baltimore.ie email: stephen.farrell@baltimore.ie
Russell Housley Russell Housley
SPYRUS SPYRUS
381 Elden Street 381 Elden Street
Suite 1120 Suite 1120
Herndon, VA 20170 Herndon, VA 20170
USA USA
tel: +1-703-707-0696 tel: +1-703-707-0696
skipping to change at line 1783 skipping to change at page 38, line 4
ACClearAttrs ::= SEQUENCE { ACClearAttrs ::= SEQUENCE {
acIssuer GeneralName, acIssuer GeneralName,
acSerial INTEGER, acSerial INTEGER,
attrs SEQUENCE OF Attribute attrs SEQUENCE OF Attribute
} }
ProxyInfo ::= SEQUENCE OF Targets ProxyInfo ::= SEQUENCE OF Targets
END END
Appendix C: Change History
<<This Appendix to be deleted before RFC>>
This appendix lists major changes since the previous revision.
Major changes since last revision:
Changes from -05 to -06:
1. Added new item 1 to validation rules in section 5.
2. Added security considerations text about "rogue" CAs.
3. Changed to allow holder.entityName = PKC.subject or
PKC.subjectAltName for the relevant cases & clarified that Holder
should only have one value.
4. Changed to insist on version 2 to avoid clash with possibly ISO
syntax issue.
5. Updated references.
Changes from -04 to -05:
1. Changed from referencing rfc2459 to new-part1 and pkalgs.
Changes from -03 to -04
1. Folding in last call comments.
2. Last bits of synchronizing with X.509 2000 spec.
Changes from -02 to -03
1. Many minor editorial changes
2. Changed OID max element arc text in app. A
3. Removed restriction on Clearance SecurityValue syntaxes to allow
support for various existing clearance schemes
4. Finalized alignment with 4th edition of X.509
Changes from -01 to -02
1. Re-Synchronized with X.509 DAM
2. Deleted AC chains concept
3. Moved AAControls to "optional features" section
4. Samples will be a separate draft
5. Revocation: now using X.509 DAM (noRevAvail) and standard 2459
mechanisms only
6. Deleted the special wildcard target "ALL"
Changes from -00 to -01
1. Re-structured conformance to profile + options as per Oslo
consensus
2. Moved acquisition protocol (LAAP)_to separate I-D
3. Removed restrictions entirely
4. Added new AC revocation options
5. Added optional support for use of objectDigestInfo for keys
6. Added optional support for chains of ACs
7. Changed some syntax:
Added UTF8String to IetfAttrSyntax value choice
Split target & proxy extensions, removed owner from proxyInfo
8. Allocated PKIX OIDs (note: check with repository before using
these, the PKIX arc is currently available at
http://www.imc.org/ietf-pkix/pkix-oid.asn)
9. Added compiled ASN.1 module
 End of changes. 19 change blocks. 
79 lines changed or deleted 104 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/