Skip to main content

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 5280

Revision differences

Document history

Date Rev. By Action
2020-01-21
11 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2017-05-16
11 (System) Changed document authors from "Dave Cooper" to "Dave Cooper, Sharon Boeyen, Stefan Santesson, William Polk, Russ Housley, Stephen Farrell"
2016-03-08
Naveen Khan Posted related IPR disclosure: Collective Rights under Settlement (Glassey/McNeil)'s Statement about IPR related to draft-barnes-geopriv-secure-location-object and draft-ietf-pkix-rfc3280bis
2015-10-14
11 (System) Notify list changed from pkix-chairs@ietf.org, tim.polk@nist.gov, housley@vigilsec.com to tim.polk@nist.gov, housley@vigilsec.com
2008-05-09
11 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2008-05-09
11 Cindy Morgan [Note]: 'RFC #5280' added by Cindy Morgan
2008-05-08
11 (System) RFC published
2008-02-19
11 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2008-02-15
11 (System) IANA Action state changed to No IC from In Progress
2008-02-15
11 (System) IANA Action state changed to In Progress
2008-02-15
11 Amy Vezza IESG state changed to Approved-announcement sent
2008-02-15
11 Amy Vezza IESG has approved the document
2008-02-15
11 Amy Vezza Closed "Approve" ballot
2008-02-15
11 Russ Housley State Changes to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed by Russ Housley
2008-02-13
11 (System) New version available: draft-ietf-pkix-rfc3280bis-11.txt
2008-01-10
11 Amy Vezza State Changes to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation by Amy Vezza
2008-01-10
11 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2008-01-10
11 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-01-10
11 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-01-10
11 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2008-01-10
11 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2008-01-10
11 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-01-10
11 Chris Newman
[Ballot comment]
---
      An explicitText field includes the textual statement directly in
      the certificate.  The explicitText field is a …
[Ballot comment]
---
      An explicitText field includes the textual statement directly in
      the certificate.  The explicitText field is a string with a
      maximum size of 200 characters.  Conforming CAs SHOULD use the
      UTF8String encoding for explicitText, but MAY use IA5String.
---
Just saying IA5String or UTF8String is not sufficient for
interoperability as no guidance is provided for use of NUL, line break
semantics or other problematic control characters that are permitted in
these syntaxes.  draft-klensin-net-utf8 (presently in IETF last
call) would provide a reference to flesh out interoperability for these
text strings.  I recommend adding that reference (either normatively
or informatively) to improve the document.

  name) extension MUST be used; however, a DNS name MAY be represented
  in the subject field using the domainComponent attribute as described
  in section 4.1.2.4.
I'm not convinced this accurately reflects practice.  I've never seen
dc components used to represent a domain in a certificate.  When I've
seen them used in LDAP, they represent the DIT location for
domain-related attributes, something quite different from the domain
name itself.  However, I've frequently seen a domain encoded in a
certificate subject as the value of the "CN=" attribute and TLS
software failing to support that may not interoperate well.  Support
for domain in CN is a MUST in the widely deployed RFC 2818.  I'm not
sure it's wise to mention a third encoding of domain in certificates
when support for two encodings is already needed by real-world
implementations.

  the address MUST be stored in the rfc822Name.  The format of an
  rfc822Name is an "addr-spec" as defined in [RFC 2822].  An addr-spec

It's generally better to refer to RFC 2821 for the syntax of email
addresses.  However given the unfortunate name of this field, I instead
recommend you add a sentence that discourages use of comments, folding
whitespace and obsolete syntax that RFC 2822 permits in an
addr-spec as none of those features will interoperate well in this
context.

    Note that an addr-spec has no
  phrase (such as a common name) before it, has no comment (text
  surrounded in parentheses) after it, and is not surrounded by "<" and
  ">".
The second clause of this sentence is not correct.  RFC 2822 addr-spec
ABNF does permit comments at the end (as well as at the beginning and
on either side of the '@' sign).

  Implementations should convert IRIs to Unicode before display.
  Specifically, conforming implementations should perform the
  conversion operation specified in section 3.2 of [RFC 3987].

Typo, where this says "IRIs" it meant to say "URIs".  Q: is lower case
should intentional here?

I have reviewed section 7 and consider it sufficient otherwise.
2008-01-09
11 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-01-09
11 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-01-09
11 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-01-09
11 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-01-08
11 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-01-08
11 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2008-01-03
11 Tim Polk [Ballot Position Update] New position, Recuse, has been recorded by Tim Polk
2008-01-03
11 Russ Housley [Ballot Position Update] New position, Recuse, has been recorded by Russ Housley
2008-01-03
11 Sam Hartman Note field has been cleared by Sam Hartman
2008-01-03
11 Sam Hartman State Changes to IESG Evaluation from Waiting for Writeup by Sam Hartman
2008-01-03
11 Sam Hartman Telechat date was changed to 2008-01-10 from 2007-12-20 by Sam Hartman
2008-01-03
11 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded for Sam Hartman
2008-01-03
11 Sam Hartman Ballot has been issued by Sam Hartman
2008-01-03
11 Sam Hartman Created "Approve" ballot
2008-01-03
11 Sam Hartman Placed on agenda for telechat - 2008-01-10 by Sam Hartman
2007-12-21
10 (System) New version available: draft-ietf-pkix-rfc3280bis-10.txt
2007-12-19
11 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Ran Canetti.
2007-12-17
11 Sam Hartman Removed from agenda for telechat - 2007-12-20 by Sam Hartman
2007-12-14
11 (System) State has been changed to Waiting for Writeup from In Last Call by system
2007-12-14
11 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2007-12-13
11 Sam Hartman Placed on agenda for telechat - 2007-12-20 by Sam Hartman
2007-12-13
11 Sam Hartman [Note]: 'new version expected to be submitted Friday to address last call comments' added by Sam Hartman
2007-12-02
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Ran Canetti
2007-12-02
11 Samuel Weiler Request for Last Call review by SECDIR is assigned to Ran Canetti
2007-11-30
11 Amy Vezza Last call sent
2007-11-30
11 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2007-11-29
11 Sam Hartman Last Call was requested by Sam Hartman
2007-11-29
11 Sam Hartman State Changes to Last Call Requested from AD Evaluation by Sam Hartman
2007-11-29
11 (System) Ballot writeup text was added
2007-11-29
11 (System) Last call text was added
2007-11-29
11 (System) Ballot approval text was added
2007-10-12
09 (System) New version available: draft-ietf-pkix-rfc3280bis-09.txt
2007-07-05
11 Sam Hartman State Changes to AD Evaluation from Publication Requested by Sam Hartman
2007-07-05
11 Sam Hartman Wanted to understand the IDNA internationalization issues better before starting on this.
I've done this so now I start
2007-06-15
11 Sam Hartman State Change Notice email list have been change to pkix-chairs@tools.ietf.org, tim.polk@nist.gov, housley@vigilsec.com from pkix-chairs@tools.ietf.org
2007-06-15
11 Sam Hartman Responsible AD has been changed to Sam Hartman from Tim Polk
2007-06-15
11 Dinara Suleymanova
PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe …
PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

I reviewed this I-D and  I feel is it ready for publication, modulo minor copy editing improvements. Stefan Santesson, my co-chair, is an author and thus he did not participate in this review.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

This document has undergone a VERY thorough review by the WG.  This document is an update of the certificate and CRL profile that is the cornerstone standard for use of X.509 technology in the IETF. The update was motivated by the need to track IETF support for internationalized names, discovery of several minor errors in 3280, and by the need for clarifications to the text based on experience with the interpretation of RFC 3280. All of the major contributors to PKIX have contributed to and or commented on this document.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

WG consensus is solid. As usual there are a couple of folks who would like to make even more, minor changes, but the WG believes that we have worked on this version long enough and it is time to publish.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The I-D was processed using the idnits program. It identified 1 error ( an obsolete normative reference) and seven warnings, all of which will be easy to fix.  There were also 15 comments; most appear to have been erroneously triggered by the ASN.1.

  1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

The document contains both types of references, and they are clearly labeled. All normative  references cite RFCs or ISO standards (necessary since this document is a profile of ISO standards).

Document Write-up

Technical Summary

This document is a replacement for RFC 3280, the standard that profiles X.509 certificate and CRL syntax for use in the IETF. RFC 3280 needed to be updated to track IETF support for internationalized names, to correct errors that have been discovered since the publication of 3280 five years ago. As part of the update, the specification of the AIA certificate extension (an IETF "private" extension) was incorporated into the document, instead of being a standalone RFC. (4325). The document also updates the reference to the list of supported algorithms used with certificates. The authors made a minor modification to the text to make clear that hash algorithms other than SHA-1 can be used in certain places, consistent with Security Area policy to make all of our standards independent of specific hash algorithms. The security considerations section was expanded, to cal attention to more subtle (DoS) concerns that may arise in some contexts. Despite the numerous tweaks and fixes,  most of the text in this document is unchanged form 3280. The end of the introduction section  of this document clearly summarizes the differences between it and RFC 3280.

Working Group Summary

The working group expressed consensus to advance the draft to Proposed Standard.

Protocol Quality

This document has been reviewed by members of the ietf-pkix@imc.org mailing list and by the working group chairs. The updated spec is a needed improvement over 3280 and should be published.
2007-06-15
11 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2007-02-23
08 (System) New version available: draft-ietf-pkix-rfc3280bis-08.txt
2006-12-28
07 (System) New version available: draft-ietf-pkix-rfc3280bis-07.txt
2006-11-15
06 (System) New version available: draft-ietf-pkix-rfc3280bis-06.txt
2006-10-19
05 (System) New version available: draft-ietf-pkix-rfc3280bis-05.txt
2006-06-27
04 (System) New version available: draft-ietf-pkix-rfc3280bis-04.txt
2006-05-24
03 (System) New version available: draft-ietf-pkix-rfc3280bis-03.txt
2006-01-13
02 (System) New version available: draft-ietf-pkix-rfc3280bis-02.txt
2005-07-20
01 (System) New version available: draft-ietf-pkix-rfc3280bis-01.txt
2005-04-15
00 (System) New version available: draft-ietf-pkix-rfc3280bis-00.txt