Skip to main content

An Internet Attribute Certificate Profile for Authorization
RFC 5755

Revision differences

Document history

Date Rev. By Action
2020-01-21
05 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
05 (System) Notify list changed from pkix-chairs@ietf.org, draft-ietf-pkix-3281update@ietf.org to (None)
2013-07-24
05 (System) IANA Action state changed to No IC from In Progress
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Robert Sparks
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2010-01-25
05 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2010-01-25
05 Cindy Morgan [Note]: 'RFC 5755' added by Cindy Morgan
2010-01-25
05 (System) RFC published
2009-07-27
05 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-07-27
05 (System) IANA Action state changed to In Progress
2009-07-27
05 Amy Vezza IESG state changed to Approved-announcement sent
2009-07-27
05 Amy Vezza IESG has approved the document
2009-07-27
05 Amy Vezza Closed "Approve" ballot
2009-07-27
05 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2009-07-26
05 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2009-05-22
05 (System) Removed from agenda for telechat - 2009-05-21
2009-05-14
05 Tim Polk Placed on agenda for telechat - 2009-05-21 by Tim Polk
2009-04-28
05 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2009-04-27
05 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to Yes from Discuss by Alexey Melnikov
2009-04-27
05 Alexey Melnikov [Ballot discuss]
2009-04-27
05 Alexey Melnikov [Ballot comment]
2009-04-27
05 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks
2009-04-27
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-04-27
05 (System) New version available: draft-ietf-pkix-3281update-05.txt
2009-04-23
05 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead by Cindy Morgan
2009-04-23
05 Jari Arkko [Ballot discuss]
I would like to talk about the document's normative reference to
RFC 3281 (yes, the same one that the document is also deprecating).
2009-04-23
05 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2009-04-23
05 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-04-23
05 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-04-22
05 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2009-04-22
05 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-04-22
05 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-04-22
05 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-04-21
05 Dan Romascanu
[Ballot discuss]
If I understand well the current rules and the latest interpretation given by the Legal Counsel of the IETF, the code in Appendix …
[Ballot discuss]
If I understand well the current rules and the latest interpretation given by the Legal Counsel of the IETF, the code in Appendix B should include the (long version) copyright notice in "code" similarly to MIB modules and such.
2009-04-21
05 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2009-04-20
05 Robert Sparks
[Ballot comment]
The diff between this and 3281 is pretty simple. The deletion of this sentence (near the end of page 32 of 3281 update) …
[Ballot comment]
The diff between this and 3281 is pretty simple. The deletion of this sentence (near the end of page 32 of 3281 update) sticks out on casual inspection: "In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present." I wanted to shine the light on it to make sure its deletion was intentional.
2009-04-20
05 Robert Sparks
[Ballot discuss]
I don't think the following normative reference is stable enough:

[RFC3281-ERR] http://www.rfc-editor.org/errata_search.php?eid=302

1) The content behind that link can change significantly …
[Ballot discuss]
I don't think the following normative reference is stable enough:

[RFC3281-ERR] http://www.rfc-editor.org/errata_search.php?eid=302

1) The content behind that link can change significantly over time
2) The link, as expressed, puts a constraint (read burden for the maintainers) on how the errata_search tool works going forward.

Could the single correction in that errata be captured as a note in this document instead?
2009-04-20
05 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks
2009-04-20
05 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-04-20
05 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-04-20
05 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2009-04-20
05 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2009-04-20
05 Adrian Farrel [Ballot comment]
s/IPSec/IPsec/  x2
2009-04-20
05 Alexey Melnikov
[Ballot comment]
In general I think this is a well written document and I was planning to vote "Yes" originally.
Here are some other comments …
[Ballot comment]
In general I think this is a well written document and I was planning to vote "Yes" originally.
Here are some other comments that might be worth addressing:

1.2. AC Path Delegation

[...]

  Since the administration and processing associated with such AC
  chains is complex and the use of ACs in the Internet today is quite
  limited, this specification does NOT RECOMMEND the use of AC chains.

NOT RECOMMEND is not a RFC 2119 keyword ("NOT RECOMMENDED" is).


                        Figure 1: AC Exchanges

Having arrows with direction of flows would be helpful here




4.3.4. Authority Information Access

  The authorityInformationAccess extension, as defined in [PKIXPROF],
  MAY be used to assist the AC verifier in checking the revocation
  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 make it look as if this is an RFC 2119 contstruct, but it
isn't. I suggest rewording.


Also, a reference to section 4.2.2.1 of RFC 5280 is going to be useful here, as a search for "authorityInformationAccess" in RFC 5280 yields no result.


5. Attribute Certificate Validation

[...]

  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

Why use of SHOULD here? Suggest not using RFC 2119 in this case. I.e.
"Where the extension value causes the AC ...".

      AC verifier MUST reject the AC.


7.1. Attribute Encryption

[...]

  The procedure for an AC issuer when encrypting attributes is
  illustrated by the following (any other procedure that gives the same
  result MAY be used):

    1.    Identify the sets of attributes that 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 ContentInfo containing the EnvelopedData as a
              value of the encAttrs attribute.
        2.3. Ensure the cleartext attributes are not present in the
              to-be-signed AC.
    3.  Add the encAttrs (with its multiple values) to the AC.

  Note that there may be more than one attribute of the same type (the
  same OBJECT IDENTIFIER) after decryption.  That is, an AC MAY contain
  the same attribute type both in clear and in encrypted form (and
  indeed several times if the same recipient is associated with more
  than one EnvelopedData).

I admit I might be confused here, but I have 2 questions:

1). Is this MAY requirement only stated in this section? I can't think of
a case when both an encrypted and an unencrypted attribute of the same type are present. Note that I can see a case when several encrypted attributes of the same type are present.

2). Shouldn't the text in () talk about *different* recipients?

  One approach implementers may choose, would
  be to merge attribute values following decryption in order to re-
  establish the "once only" constraint.


In section 8:

  There is often a requirement to map between the authentication
  supplied by a particular security protocol (e.g. TLS, S/MIME) and the
  AC holder's identity.  If the authentication uses PKCs, then this
  mapping is straightforward.  However, it is envisaged that ACs will
  also be used in environments where the holder may be authenticated
  using other means.  Implementers SHOULD be very careful in mapping
  the authenticated identity to the AC holder.

Can you elaborate on what problem the last sentence in Section 8
is trying to address? Is this referring to insecure mappings, or something else?
2009-04-20
05 Alexey Melnikov
[Ballot discuss]
(Updated the DISCUSS portion)

4.2. Profile of Standard Fields

  GeneralName offers great flexibility.  To achieve interoperability,
  in spite of this flexibility, …
[Ballot discuss]
(Updated the DISCUSS portion)

4.2. Profile of Standard Fields

  GeneralName offers great flexibility.  To achieve interoperability,
  in spite of this flexibility, this profile imposes constraints on the
  use of GeneralName.

  Conforming implementations MUST be able to support the dNSName,
  directoryName, uniformResourceIdentifier, and iPAddress options. This
  is compatible with the GeneralName requirements in [PKIXPROF] (mainly
  in section 4.2.1.6).

What about SRVName define in:
  [X509-SRV]
              Santesson, S., "Internet X.509 Public Key Infrastructure
              Subject Alternative Name for Expression of Service Name",
              RFC 4985, August 2007.
?

Many Apps protocols are starting to recommend use of SRVName, so having a MUST/SHOULD here about them would improve consistency across protocols.

In Appendix A Object Identifiers:

  This (normative) appendix lists the new object identifiers which are
  defined in this specification.  Some of these are required only for
  support of optional features and are not required for conformance to
  this profile.  This specification mandates support for OIDs which
  have arc elements with values that are less than 2^32, (i.e. they
  MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less
  than 2^31 (i.e. less than or equal to 2,147,483,647).  This allows
  each arc element to be represented within a single 32 bit word.
  Implementations MUST also support OIDs where the length of the dotted
  decimal (see [LDAP], section 4.1.2) string representation can be up

RFC 4510 ([LDAP]) doesn't have section 4.1.2.
I think you want to reference Section 1.4 in RFC 4512.

In Appendix B ASN.1 Module:

  NOTE: The value for TBA will be included during AUTH48.

  //** RFC Editor: Remove this note prior to publication **//

  PKIXAttributeCertificate-2008 { iso(1) identified-organization(3)
    dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-attribute-cert2(TBA) }

But the IANA section says that no IANA action is required.
Where is this TBA coming from?
2009-04-19
05 Alexey Melnikov
[Ballot comment]
In general I think this is a well written document and I was planning to vote "Yes" originally.
Here are some other comments …
[Ballot comment]
In general I think this is a well written document and I was planning to vote "Yes" originally.
Here are some other comments that might be worth addressing:

1.2. AC Path Delegation

[...]

  Since the administration and processing associated with such AC
  chains is complex and the use of ACs in the Internet today is quite
  limited, this specification does NOT RECOMMEND the use of AC chains.

NOT RECOMMEND is not a RFC 2119 keyword ("NOT RECOMMENDED" is).


                        Figure 1: AC Exchanges

Having arrows with direction of flows would be helpful here




4.3.4. Authority Information Access

  The authorityInformationAccess extension, as defined in [PKIXPROF],
  MAY be used to assist the AC verifier in checking the revocation
  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 make it look as if this is an RFC 2119 contstruct, but it
isn't. I suggest rewording.


Also, a reference to section 4.2.2.1 of RFC 5280 is going to be useful here, as a search for "authorityInformationAccess" in RFC 5280 yields no result.


5. Attribute Certificate Validation

[...]

  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

Why use of SHOULD here? Suggest not using RFC 2119 in this case. I.e.
"Where the extension value causes the AC ...".

      AC verifier MUST reject the AC.


7.1. Attribute Encryption

[...]

  The procedure for an AC issuer when encrypting attributes is
  illustrated by the following (any other procedure that gives the same
  result MAY be used):

    1.    Identify the sets of attributes that 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 ContentInfo containing the EnvelopedData as a
              value of the encAttrs attribute.
        2.3. Ensure the cleartext attributes are not present in the
              to-be-signed AC.
    3.  Add the encAttrs (with its multiple values) to the AC.

  Note that there may be more than one attribute of the same type (the
  same OBJECT IDENTIFIER) after decryption.  That is, an AC MAY contain
  the same attribute type both in clear and in encrypted form (and
  indeed several times if the same recipient is associated with more
  than one EnvelopedData).

I admit I might be confused here, but I have 2 questions:

1). Is this MAY requirement only stated in this section? I can't think of
a case when both an encrypted and an unencrypted attribute of the same type are present. Note that I can see a case when several encrypted attributes of the same type are present.

2). Shouldn't the text in () talk about *different* recipients?

  One approach implementers may choose, would
  be to merge attribute values following decryption in order to re-
  establish the "once only" constraint.


In section 8:

  There is often a requirement to map between the authentication
  supplied by a particular security protocol (e.g. TLS, S/MIME) and the
  AC holder's identity.  If the authentication uses PKCs, then this
  mapping is straightforward.  However, it is envisaged that ACs will
  also be used in environments where the holder may be authenticated
  using other means.  Implementers SHOULD be very careful in mapping
  the authenticated identity to the AC holder.

Can you elaborate on what problem the last sentence in Section 8
is trying to address?
2009-04-19
05 Alexey Melnikov
[Ballot discuss]
In Appendix A Object Identifiers:

  This (normative) appendix lists the new object identifiers which are
  defined in this specification.  Some of …
[Ballot discuss]
In Appendix A Object Identifiers:

  This (normative) appendix lists the new object identifiers which are
  defined in this specification.  Some of these are required only for
  support of optional features and are not required for conformance to
  this profile.  This specification mandates support for OIDs which
  have arc elements with values that are less than 2^32, (i.e. they
  MUST be between 0 and 4,294,967,295 inclusive) and SHOULD be less
  than 2^31 (i.e. less than or equal to 2,147,483,647).  This allows
  each arc element to be represented within a single 32 bit word.
  Implementations MUST also support OIDs where the length of the dotted
  decimal (see [LDAP], section 4.1.2) string representation can be up

RFC 4510 ([LDAP]) doesn't have section 4.1.2.


In Appendix B ASN.1 Module:

  NOTE: The value for TBA will be included during AUTH48.

  //** RFC Editor: Remove this note prior to publication **//

  PKIXAttributeCertificate-2008 { iso(1) identified-organization(3)
    dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-attribute-cert2(TBA) }

But the IANA section says that no IANA action is required.
Where is this TBA coming from?
2009-04-19
05 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2009-04-15
05 Russ Housley [Ballot Position Update] New position, Recuse, has been recorded by Russ Housley
2009-04-15
05 Tim Polk [Ballot Position Update] New position, Yes, has been recorded for Tim Polk
2009-04-15
05 Tim Polk Ballot has been issued by Tim Polk
2009-04-15
05 Tim Polk Created "Approve" ballot
2009-04-15
05 Tim Polk Placed on agenda for telechat - 2009-04-23 by Tim Polk
2009-04-10
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-04-09
05 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Chris Lonvick.
2009-04-07
05 Amanda Baber IANA comments:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2009-04-03
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Chris Lonvick
2009-04-03
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Chris Lonvick
2009-03-27
05 Cindy Morgan Last call sent
2009-03-27
05 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2009-03-27
05 Tim Polk Last Call was requested by Tim Polk
2009-03-27
05 Tim Polk State Changes to Last Call Requested from Publication Requested by Tim Polk
2009-03-27
05 (System) Ballot writeup text was added
2009-03-27
05 (System) Last call text was added
2009-03-27
05 (System) Ballot approval text was added
2009-03-26
05 Cindy Morgan
1.a - Steve Kent is the Shepherd. I have personally reviewed the
document and assert that it is ready for IESG publication.

1.b - The …
1.a - Steve Kent is the Shepherd. I have personally reviewed the
document and assert that it is ready for IESG publication.

1.b - The document has been reviewed by key WG members. There are no
concerns about depth or breadth of the reviews.

1.c - I see no need for wider review.

1.d - There are no specific concerns of which the AD and/or IESG should
be aware.

1.e - The WG consensus is solid.

1.f - There has been no threat of an appeal by an WG members.

1.g - I have personally verified that the document satisfies all ID
nits (although it does generate several spurious warnings).

1.h - The document splits it references into normative and informative
as required.

1.i - The document has an IANA consideration and it is consistent with
the main body (there are no IANA considerations).

1.j - Sean Truner assures me that the ASN.1 has been verified :-).

1.k - Write-up is as follows:

Technical Summary

This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols. Attribute certificates may be
used in a wide range of applications and environments covering a
broad spectrum of interoperability goals and a broader spectrum of
operational and assurance requirements. The goal of this document is
to establish a common baseline for generic applications requiring
broad interoperability as well as limited special purpose
requirements. The profile places emphasis on attribute certificate
support for Internet electronic mail, IPsec, and WWW security
applications. This document obsoletes RFC 3281.

Working Group Summary

This ID was discussed on the mailing list and at multiple meetings.
It is a simple update to address known errata posted to the RFC
editor and to address an issue identified as a result of developing
the draft-ietf-pkix-authorityclearanceconstraints ID. The clearance
attribute object identifier didn't match the attribute's X.509 object
identifier.

Document Quality

This document is a short update of an existing draft and is comparable
in quality to its predecessor. Note that most of the changes listed
in Appendix C of the document are a result of the long lag time
between updates (e.g., reference updates).

Personnel

Steve Kent is the document Shepherd. Tim Polk is the responsible
Security Area AD.
2009-03-26
05 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-02-21
04 (System) New version available: draft-ietf-pkix-3281update-04.txt
2008-12-22
03 (System) New version available: draft-ietf-pkix-3281update-03.txt
2008-12-12
02 (System) New version available: draft-ietf-pkix-3281update-02.txt
2008-10-27
01 (System) New version available: draft-ietf-pkix-3281update-01.txt
2008-10-17
00 (System) New version available: draft-ietf-pkix-3281update-00.txt