As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?
Experimental
Why is this the proper type of RFC?
This document is the result of operational experience with running the
Experimental RFC 6962. Initially, this was meant to become a Standards
Track document but at draft -29 it was decided that the changes were
large enough that it should really be considered Experimental.
Is this type of RFC indicated in the title page header?
Yes, the document title page indicates being 'standard track'.
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:
Technical Summary
This document describes a protocol for publicly logging the existence
of Transport Layer Security (TLS) server certificates as they are
issued or observed, in a manner that allows anyone to audit
certification authority (CA) activity and notice the issuance of
suspect certificates as well as to audit the certificate logs
themselves. The intent is that eventually clients would refuse to
honor certificates that do not appear in a log, effectively forcing
CAs to add all issued certificates to the logs.
This document is a bis document for the Experimental RFC 6962.
The major changes between that document and this document are
listed in Section 1.3 of the draft, and are:
o Hash and signature algorithm agility: permitted algorithms are now
specified in IANA registries.
o Precertificate format: precertificates are now CMS objects rather
than X.509 certificates, which avoids violating the certificate
serial number uniqueness requirement in Section 4.1.2.2 of
[RFC5280].
o Removed precertificate signing certificates and the precertificate
poison extension: the change of precertificate format means that
these are no longer needed.
o Logs IDs: each log is now identified by an OID rather than by the
hash of its public key. OID allocations are managed by an IANA
registry.
o "TransItem" structure: this new data structure is used to
encapsulate most types of CT data. A "TransItemList", consisting
of one or more "TransItem" structures, can be used anywhere that
"SignedCertificateTimestampList" was used in [RFC6962].
o Merkle tree leaves: the "MerkleTreeLeaf" structure has been
replaced by the "TransItem" structure, which eases extensibility
and simplifies the leaf structure by removing one layer of
abstraction.
o Unified leaf format: the structure for both certificate and
precertificate entries now includes only the TBSCertificate
(whereas certificate entries in [RFC6962] included the entire
certificate).
o SCT extensions: these are now typed and managed by an IANA
registry.
o STH extensions: STHs can now contain extensions, which are typed
and managed by an IANA registry.
o API outputs: complete "TransItem" structures are returned, rather
than the constituent parts of each structure.
o get-all-by-hash: new client API for obtaining an inclusion proof
and the corresponding consistency proof at the same time.
o Presenting SCTs with proofs: TLS servers may present SCTs together
with the corresponding inclusion proofs using any of the
mechanisms that [RFC6962] defined for presenting SCTs only.
(Presenting SCTs only is still supported).
o CT TLS extension: the "signed_certificate_timestamp" TLS extension
has been replaced by the "transparency_info" TLS extension.
o Other TLS extensions: "status_request_v2" may be used (in the same
manner as "status_request"); "cached_info" may be used to avoid
sending the same complete SCTs and inclusion proofs to the same
TLS clients multiple times.
o TLS Feature extension: this certificate extension may be used by a
CA to indicate that CT compliance is required.
o Verification algorithms: added detailed algorithms for verifying
inclusion proofs, for verifying consistency between two STHs, and
for verifying a root hash given a complete list of the relevant
leaf input entries.
o Extensive clarifications and editorial work.
o Clarifications for use with TLS v1.2 and v1.3
Backwards compatibility:
Logs can either conform to RFC6962 (???v1???) or RFC6962??bis (???v2???),
not both, as the format of the data logged is different. As v1 and
v2 SCTs are delivered using different X.509, TLS and OCSP extensions,
they can mostly co??exist and TLS clients can support both
simultaneously. One provision has been made for embedded v1 and
v2 SCTs by requiring v2 clients to remove v1 SCTs from the
TBSCertificate portion of the certificate before validating v2 SCTs
over it (to allow v2 SCTs to be embedded before v1 SCTs are issued).
Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?
During the document development, some content was split of
into other documents for clarity. Topics split of covers a threat
model document, a log monitoring API, and a client/gossip API.
Name redaction has been considered and was split of in another
document as well. The WG is still discussing whether or not to
allow name redaction as well as the redaction method that would
be used.
Currently, there is still an open issue between some major vendors
about whether this document is good enough as a basis to develop
further preventative client actions on. The WG Chairs are organising
a meeting with these parties to determine if the document should be
stalled or proceed.
Document Quality
Are there existing implementations of the protocol?
There are various implementations in different state of completion
which have lead to updates to the document.
Various well-known crypto libraries have started implementation.
Have a significant number of vendors indicated their plan to implement
the specification?
Yes. Various well-known crypto libraries have started implementation.
A few new independent parties have also implemented or mostly
implemented this document's specification - both proprietary as well
as opensource implementations.
Are there any reviewers that merit special mention as having done
a thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?
Stephen Kent gave many in-depth reviews of many versions of the
document, all of which were dealt with by the Working Group. Daniel
Kahn Gillmor came up with a new attack, which is now described in one
of the documents that was split off from this one. During WGLC several
implementers came forward explaining that one MUST keyword (in Section
5.1) had to change to SHOULD to allow for log behaviour that was deemed
necessary for actual deployments, which was agreed on by the Working
Group.
If there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?
There was no such review.
Personnel
Who is the Document Shepherd?
Paul Wouters
Who is the Responsible Area Director?
Roman Danyliw (Eric Rescorla before him, as this document has taken a long time)
(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
I read all the threads about this document on the mailing list to be
sure that the issues raised were address or at least discussed in the WG.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No. The document has been seen and is (being) implemented widely in
various different parts of the industry and opensource communities.
There is significant interest and traction to roll-out implementations
of this document.
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
No. The important groups that needed to read and comment on this
document were the PKIX and TLS communities and these groups were
very well represented.
(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
No concerns other than taking more time to publish.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
[PAUL: Do I need to click on the IPR button in the datatracker before
submitting this? ]
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Not that the WG chairs are aware of.
(9) 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?
It represents strong consensus within the WG, which includes many
relevant affected players in the industry (CA vendors, browser
vendors, TLS implementors, crypto library authors). The only item
which did not have strong consensus was name redaction, which has
therefore been moved to its own document for possible future work.
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Appeals were threatened in the past, but have been resolved.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
The idnits tool shows a few warnings:
== There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
These are false positives (I think it is reading OID's as IPv6?)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
That is correct. That is TLS v1.2 and the document specifically talks about TLS v1.2 and v1.3
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
N/A
(13) Have all references within this document been identified as
either normative or informative?
Yes.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
No.
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
There is one. RFC 6979 "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)"
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Yes. It obsoletes RFC 6962.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
It has been reviews and complies with the requirements of RFC-5226
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
The IANA is requested to create the "Public Notary Transparency"
registry. Within that registry, the following sub registries are requested
to be created:
Section Registry Name
10.2.1 Hash Algorithms
10.2.2 Signature Algorithms
10.2.3 VersionedTransTypes
10.2.4 Log Artifact Extensions
10.2.5 Log ID Registry
10.2.6 Error Types
[note: Log ID Registry should probably just be called Log IDs ?]
All of these Registries are defined to require Expert Review. An Expert
should be a person that has intimate knowledge of TLS, PKIX and cryptography.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
The idnits checker was used on the document.