Certificate Transparency
draft-laurie-pki-sunlight-12

[Ballot discuss]
(1) This document needs clarification as to what security
properties are being guaranteed, and under what operational
assumptions.  The document seems to assume, but does not
state, something like the following operational model:

  1. Certificate is published to log
  2. Potential subjects of certificates examine the log for
    mis-issued certificates
  3. If a mis-issued certificate is found, it is revoked

If steps (2) or (3) don't happen for a given site, then there
is no security benefit -- all inclusion in the log would mean is
"this certificate exists".  And in reality, (2) and (3) will not
happen for all sites.  So the semantic of a certificate being
included in a log is basically the following: "The subject of
this certificate has been given the opportunity to ask for it
to be revoked."  The document should clarify this security
model, for example by adding text like the above.

(2) The pre-cert dance:

"""
  "tbs_certificate" is the DER encoded TBSCertificate (see [RFC5280])
  component of the Precertificate - that is, without the signature and
  the poison extension.
"""

Please clarify that this Precertificate dance is ONLY useful
to subjects, not to clients.  The SCT for a Precertificate is
useless for TLS, since the certificate will be invalid anyway
(via the poison extension).

(3) Please clarify why the Poison extension is removed from the
Precertificate's TBSCertificate before inclusion in the SCT.
This clarity is necessary for the protocol to be implementable,
since clients, CAs, and subjects need to knwo what to do with
these Precertificates and their SCTs.

[Ballot discuss]
[Update (28 Mar 2013): Moved several more minor points to COMMENT]

This document would benefit from several clarifications as to what security
properties are being guaranteed, and under what operational assumptions.  The
document seems to assume, but does not state, something like the following
operational model:

1. Certificate is published to log
2. Potential subjects of certificates examine the log for mis-issued
certificates 3. If a mis-issued certificate is found, it is revoked

If steps (2) and (3) don't happen for a given site, then there is no security
benefit -- all inclusion in the log would mean is "this certificate exists",
which is apparent enough from its being used in TLS.  And in reality, (2) and
(3) will not be followed for all sites.  So the semantic of a certificate being
included in a log is basically the following: "The subject of this certificate
has been given the opportunity to ask for it to be revoked."  The document
should clarify this security model.

Several specific edits on this overall theme follow.

[Update (28 Mar 2013): This is an Experimental document.  In order for the
experiment to be run, the parties involved each need to know what they need
to do to participate.  So the focus of this DISCUSS is on clarifying what
each party needs to do in order to implement this experiment in such a way
that the desired security properties are achieved.]


"""
  "tbs_certificate" is the DER encoded TBSCertificate (see [RFC5280])
  component of the Precertificate - that is, without the signature and
  the poison extension.
"""

Please clarify that this Precertificate dance is ONLY useful to subjects, not
to clients.  The SCT for a Precertificate is useless for TLS, since the
certificate will be invalid anyway (via the poison extension).  Given this
obvservation, it's not clear why the Poison extension is removed from the
Precertificate's TBSCertificate before inclusion in the SCT.

[Update (28  Mar 2013): This clarity is necessary for the protocol to be
implementable, since clients, CAs, and subjects need to knwo what to do with
these Precertificates and their SCTs.]

[Ballot comment]
It is customary for the authors to list their affiliation on the title page.


"""
  When a
  chain is submitted to a log, a signed timestamp is returned, which
  can later be used to provide evidence to clients that the chain has
  been submitted.  TLS clients can thus require that all certificates
  they see have been logged.
"""

This last sentence seems irrelevant. Do you mean that IF a client requires certs to be logged, THEN this allows them to verify?  Suggest clarifying that this enables the requirement by providing a simple verification mechanism (vs. checking the logs directly).

This protocol uses several OIDs from the Google vendor arc (1.3.6.1.4.1.11129).
Should these be re-assigned somewhere under the IETF Experimental arc
(1.3.6.1.3)?

"""
  The intent is that eventually
  clients would refuse to honor certificates which do not appear in a
  log, effectively forcing CAs to add all issued certificates to the
  logs.
"""

This sentence makes big assumptions about reality and values.  Suggest
rewording in a more neutral way, e.g.: "If eventually, clients refuse to honor
certificates that do not appear in a log, the CAs will effectively be forced to
add all issued certificates."  It would also be helpful to add a brief
statement of why forcing CAs to list all certificates would be a good thing,
since this might not be obvious to all readers.

In the first paragraph of the Informal Introduction, several important terms
are used without definition. -- "misissued" -- "publicly auditable" --
"correctness of each log" Clearly defining these terms will help clarify the
security model.

It's an overstatement to say that logs "ensure" that interested parties can
detect mis-issue, since certificates might not be entered into the logs.
Suggest "provide a channel for".

"""
  Anyone can submit certificates to certificate logs for public
  auditing, however, since certificates will not be accepted by TLS
  clients unless logged, it is expected that certificate owners or
  their CAs will usually submit them.
"""

Assuming an operational model.  Suggested text: "..., however, since unlogged
certificates will not be accepted by TLS clients implementing this
specification, it would be advantageous for certificate owners and CAs to
submit them."

"""
  TLS clients MUST reject SCTs whose timestamp is in the future.
"""

In light of the latency involved in steps (2) and (3), it would probably be
good to recommend that if clients are using inclusion in the log as a measure
of security, then they should impose some delay on SCTs.  That is, not only
should they reject SCTs from the future, they should reject SCTs that are less
than a few days ago.

"""
  Misissued certificates that have not been publicly logged, and thus
  do not have a valid SCT, will be rejected by TLS clients.
"""

s/TLS clients/TLS clients implementing this specification/

[Ballot discuss]
0) Cleared ...

1) s4.*: Have just watched a similar URI scheme get changed by the the APPs directorate review, I'm curious why this wasn't changed to well-known URI scheme?  Don't they need to follow what's in RFC 5875?

[Ballot discuss]
since this is presumably a real thing already, I'd like to see some evidence of it's operational implications having been discussed someplace.

If I see that I'm happy to clear this.

[Ballot discuss]
0) This is discuss-discuss (i.e., no action for the authors and honestly no action for the AD I just want to go on record and then clear)

The IANA assignment from which the TLS extension is being defined (IETF consensus) requires that

"the document and proposed assignment will
  be reviewed by the IESG and appropriate IETF WGs (or
  experts, if suitable working groups no longer exist) to
  ensure that the proposed assignment will not negatively
  impact interoperability or otherwise extend IETF protocols
  in an inappropriate or damaging manner."

Normally, all TLS extensions would be defined in the TLS WG, but this one had both IETF LCs forwarded to the TLS WG.

For all those would be TLS-extension writers be advised this is an abnormal case because defining this extension in this draft was pre-greased.

and now back to the regularly scheduled program…

1) s4.*: Have just watched a similar URI scheme get changed by the the APPs directorate review, I'm curious why this wasn't changed to well-known URI scheme?  Don't they need to follow what's in RFC 5875?

[Ballot comment]
0) s1: According to RFC 5280: r/certificate authority/certification authority
throughout

1) s3.1: Some word smithing.  I think we need to clear that the poison extension must not be processed by relying parties.

Alternatively, (root as well as intermediate) Certification Authorities
may submit a certificate to logs prior to issuance.  To do so, a
Certification Authority constructs a Precertificate and adds the poison
extension identified by the OID with the value of
(1.3.6.1.4.1.11129.2.4.3).  This extension MUST be critical and it MUST
NOT be processed by relying parties.  The extension's value is NULL, that
is the extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00).
The CA, whose basic constraints extension cA=True and key usage is set
to keyCertSign) signs the resulting TBSCertificate [RFC5280] with either

  o  the Precertificate Signing Certificate Transparency Extended
      Key Usage, whose OID is 1.3.6.1.4.1.11129.2.4.4.
      The Precertificate Signing Certificate MUST be
      directly certified by the (root or intermediate) CA certificate
      that will ultimately sign the end entity TBSCertificate yielding
      the end entity certificate (note that the log may relax standard
      validation rules to allow this, so long as the issued certificate
      will be valid),

2) s3.1: Is there any kind of dispute resolution if somebody tries to submit a Root CA certificate and the entity running the log says no?

3) s3.3: Need to specify whether the SignedCertificateTimestampList certificate extension is critical.

4) s4: Need to specify which alphabet your using.  Is it "normal" or with URL and Filename Safe?

5) Any additional constraints on the timestamps?

  The syntax is: YYYYMMDDhhmmss[.s...]Z
  Example: 19990609001326.34352Z

  The encoding MUST terminate with a "Z" (which means "Zulu" time). The
  decimal point element, if present, MUST be the point option ".". The
  fractional-seconds elements, if present, MUST omit all trailing 0's;
  if the elements correspond to 0, they MUST be wholly omitted, and the
  decimal point element also MUST be omitted.

6) Why wasn't a GET/POST method described for s4.7?  Whould it' be like GET https:///ct/v1/get-roots

No inputs

Outputs

  certificates  An array of base64 encoded root certificates that are
      acceptable to the log.

7) Probably adding in s6, to make it clear what else got registered.

This document also defines an X.509 Certificate EKU, two X.509 Certificate extensions as well as an OCSP extension.  The Object Identifiers for these are assigned from a Google Arc and no further action is required of IANA for these values.

8) Just so I'm following along: TLS client must support all three mechanisms in s3.3, the SCT is signed by either ECDSA or RSA, so clients need to support both ECDSA and RSA?  I'm fine with that just curious though.

9) Any reason to not reference FIPS 186-4?  Might just be that you're using XML2RFC and it's database is out of date.

  [SHS]      National Institute of Standards and Technology, "Federal
              Information Processing Standard Publication 180-4: Secure
              Hash Standard (SHS)", March 2012, .

10) Yet another nitty thing about the reference to DSS for ECDSA.  We've really tried to get folks to start pointing to RFC 6090.  If the hash and curve are matched as they are here I've been told the outputs of RFC 6090 and DSS are the same. Any chance you could point there instead?

11) I know it's just an experiment, but do we need to have a registry policy for CtExtensions?

12) Maybe another thing for future study is how to get the log's public key to clients.

[Ballot comment]
Blech. I hate docs written in terms of code and APIs. Makes for brittle implementations. If this thing ever gets on the standards track, I hope it is rewritten with actual data format diagrams and protocol instructions. But as an experiment: Have at it.

[Ballot comment]
Blech. I hate docs written in terms of code an APIs. Makes for brittle implementations. If this thing ever gets on the standards track, I hope it is rewritten with actual data format diagrams and protocol instructions. But as an experiment: Have at it.

[Ballot comment]
It might be interesting to talk about what one of these logs would look like in practice—how big a log such as this would be for a typical CA, and what the size of a typical verification chain would be.  In general I think this is a really interesting idea and I look forward to seeing some results from the experiment.

[Ballot discuss]
The authors show no affiliation. Their email addresses indicate that
they may all work for Google.

For transparency reasons, if this is a company effort, rather than something
the authors are doing on their own time for the good of the Internet,
the authors should indicate their affiliation.

If if this is a "proprietary Google protocol made public" that should
be indicated to the reader.

[Ballot discuss]
This document would benefit from several clarifications as to what security properties are being guaranteed, and under what operational assumptions.  The document seems to assume, but does not state, something like the following operational model:

1. Certificate is published to log
2. Potential subjects of certificates examine the log for mis-issued certificates
3. If a mis-issued certificate is found, it is revoked

If steps (2) and (3) don't happen for a given site, then there is no security benefit -- all inclusion in the log would mean is "this certificate exists", which is apparent enough from its being used in TLS.  And in reality, (2) and (3) will not be followed for all sites.  So the semantic of a certificate being included in a log is basically the following: "The subject of this certificate has been given the opportunity to ask for it to be revoked."  The document should clarify this security model.

Several specific edits on this overall theme follow.

"""
  The intent is that eventually
  clients would refuse to honor certificates which do not appear in a
  log, effectively forcing CAs to add all issued certificates to the
  logs.
"""

This sentence makes big assumptions about reality and values.  Suggest rewording in a more neutral way, e.g.: "If eventually, clients refuse to honor certificates that do not appear in a log, the CAs will effectively be forced to add all issued certificates."  It would also be helpful to add a brief statement of why forcing CAs to list all certificates would be a good thing, since this might not be obvious to all readers.


In the first paragraph of the Informal Introduction, several important terms are used without definition.
-- "misissued"
-- "publicly auditable"
-- "correctness of each log"
Clearly defining these terms will help clarify the security model. 

It's an overstatement to say that logs "ensure" that interested parties can detect mis-issue, since certificates might not be entered into the logs.  Suggest "provide a channel for".


"""
  Anyone can submit certificates to certificate logs for public
  auditing, however, since certificates will not be accepted by TLS
  clients unless logged, it is expected that certificate owners or
  their CAs will usually submit them.
"""

Assuming an operational model.  Suggested text: "..., however, since unlogged certificates will not be accepted by TLS clients implementing this specification, it would be advantageous for certificate owners and CAs to submit them."


"""
  "tbs_certificate" is the DER encoded TBSCertificate (see [RFC5280])
  component of the Precertificate - that is, without the signature and
  the poison extension.
"""

Please clarify that this Precertificate dance is ONLY useful to subjects, not to clients.  The SCT for a Precertificate is useless for TLS, since the certificate will be invalid anyway (via the poison extension).  Given this obvservation, it's not clear why the Poison extension is removed from the Precertificate's TBSCertificate before inclusion in the SCT.


"""
  TLS clients MUST reject SCTs whose timestamp is in the future.
"""

In light of the latency involved in steps (2) and (3), it would probably be good to recommend that if clients are using inclusion in the log as a measure of security, then they should impose some delay on SCTs.  That is, not only should they reject SCTs from the future, they should reject SCTs that are less than a few days ago.

"""
  Misissued certificates that have not been publicly logged, and thus
  do not have a valid SCT, will be rejected by TLS clients.
"""

s/TLS clients/TLS clients implementing this specification/


This protocol uses several OIDs from the Google vendor arc (1.3.6.1.4.1.11129).  Should these be re-assigned somewhere under the IETF Experimental arc (1.3.6.1.3)?

[Ballot comment]
It is customary for the authors to list their affiliation on the title page.


"""
  When a
  chain is submitted to a log, a signed timestamp is returned, which
  can later be used to provide evidence to clients that the chain has
  been submitted.  TLS clients can thus require that all certificates
  they see have been logged.
"""

This last sentence seems irrelevant. Do you mean that IF a client requires certs to be logged, THEN this allows them to verify?  Suggest clarifying that this enables the requirement by providing a simple verification mechanism (vs. checking the logs directly).

IESG/Authors/WG Chairs:

IANA has reviewed draft-laurie-pki-sunlight-07.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We understand that, upon approval of this document, there is a single action which we must complete.

In the ExtensionType Values subregistry of the Transport Layer Security (TLS) Extensions registry located at:

http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xml

a new ExtensionType is to be registered as follows:

Value: [ TBD-at-time-of-registration ]
Extension name: signed_certificate_timestamp
Reference; [ RFC-TO-BE ]

We understand that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Certificate Transparency) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Certificate Transparency'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

As a result of comments received in the first last call and
based on additional coding, the authors are now proposing
to define a new TLS extension (see section 3.3.1) which
requires IETF review. So this is a second IETF last
call primarily intended to ensure that that change gets the
appropriate review.


Abstract


  This document describes an experimental protocol for publicly logging
  the existence of TLS certificates as they are issued or observed, in
  a manner that allows anyone to audit certificate authority 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 which do not appear in a
  log, effectively forcing CAs to add all issued certificates to the
  logs.

  Logs are network services which implement the protocol operations for
  submissions and queries that are defined in this document.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ballot/


No IPR declarations have been submitted directly on this I-D.

IANA has reviewed draft-laurie-pki-sunlight-05 and has the following comments:

IANA has a question about the IANA Action requested in this document.

IANA understands that, upon approval of this document, there is a single
IANA action which must be completed.

The request described in the IANA Considerations section of
the current draft is: "IANA is requested to allocate an RFC 5878 AuthorizationData Type for the CST included in an Authorization
Extension. The value 182 is preferred."

IANA Question -> is "CST" in this request a transposition of "SCT"?

IANA understands this request as a call to add a new value to the TLS Authorization Data Formats subregistry of the Transport Layer Security (TLS) Parameters registry located at:

http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#authorization-data-rules

IANA Question -> Is this the correct registry for the new assignment? If so, IANA understands that the authors request the value 182 to be used in the registration. What would the values for the "Description" and "DTLS-OK" subparameters be? If this is not the correct registry, could the authors provide a URL for the intended registry?

IANA understands that this is the only action required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Certificate Transparency) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Certificate Transparency'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The aim of Certificate Transparency is to have every public end-
  entity (for example, web servers) and intermediate TLS certificate
  issued by a known Certificate Authority recorded in one or more
  certificate logs.  In order to detect misissuance of certificates,
  all logs are publicly auditable.  In particular, domain owners or
  their agents will be able to monitor logs for certificates issued on
  their own domain.

  To protect clients from unlogged misissued certificates, each log
  signs all certificates it records, and clients can choose not to
  trust certificates that are not accompanied by an appropriate log
  signature.  For privacy and performance reasons log signatures are
  embedded in the TLS handshake via the TLS authorization extension, in
  a stapled OCSP extension, or in the certificate itself via an X.509v3
  certificate extension.

  To ensure a globally consistent view of any particular log, each log
  also provides a global signature over the entire log.  Any
  inconsistency of logs can be detected through cross-checks on the
  global signature.  Consistency between any pair of global signatures,
  corresponding to snapshots of a particular log at different times,
  can be efficiently shown.

  Logs are only expected to certify that they have seen a certificate,
  and thus we do not specify any revocation mechanism for log
  signatures in this document.  Logs are append-only, and log
  signatures do not expire.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd Write-up:



(1) What type of RFC is being requested (BCP, Proposed
Standard, Internet Standard, Informational, Experimental, or
Historic)? Why is this the proper type of RFC? Is this type
of RFC indicated in the title page header?

Experimental

(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:

  The aim of Certificate Transparency is to have every
public end- entity (for example, web servers) and
intermediate TLS certificate issued by a known Certificate
Authority recorded in one or more certificate logs.  In order
to detect misissuance of certificates, all logs are publicly
auditable.  In particular, domain owners or their agents will
be able to monitor logs for certificates issued on their own
domain.

  To protect clients from unlogged misissued certificates,
each log signs all certificates it records, and clients can
choose not to trust certificates that are not accompanied by
an appropriate log signature.  For privacy and performance
reasons log signatures are embedded in the TLS handshake via
the TLS authorization extension, in a stapled OCSP extension,
or in the certificate itself via an X.509v3 certificate
extension.

  To ensure a globally consistent view of any particular
log, each log also provides a global signature over the
entire log.  Any inconsistency of logs can be detected
through cross-checks on the global signature.  Consistency
between any pair of global signatures, corresponding to
snapshots of a particular log at different times, can be
efficiently shown.

  Logs are only expected to certify that they have seen a
certificate, and thus we do not specify any revocation
mechanism for log signatures in this document.  Logs are
append-only, and log signatures do not expire.

Working Group Summary:

This is an individual submission. There was a BoF on
the topic at IETF-85. Discussion has been taking place
on a dedicated list. [1]

  [1] https://www.ietf.org/mailman/listinfo/therightkey

There has been sufficient discussion for an experimental
RFC. The overall plan is to re-consider a WG after the
experimental RFC has been done and some experience with
the technology has been gained.

Document Quality:

At least Google are implementing. They say they have some CA
partners (incl. Comodo, Digicert), and some application
partners. (Not sure if public.)

Since the draft makes use of the data structure convention
from TLS and is relevant to TLS, the IETF LC will be
forwarded to that list too.

There is an open-source implementation from Google at [2]

  [2] http://code.google.com/p/certificate-transparency/

Personnel:

Who is the Document Shepherd? Who is the Responsible Area
Director?

Stephen Farrell is both shepherd and AD in this case.


(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.

As of 2012-12-20 the document is ready for IETF LC.

(4) Does the document Shepherd have any concerns about the
depth or breadth of the reviews that have been performed?

No concerns.

(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 concerns.

(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.

The AD is aware of the shepherd's concerns, if any;-)

(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?

Confirmed with authors on 2012-12-20

(8) Has an IPR disclosure been filed that references this
document? If so, summarize any WG discussion and conclusion
regarding the IPR disclosures.

No.

(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?

Has a real constituency.

(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.)

No.

(11) Identify any ID nits the Document Shepherd has found in
this document.  (See http://www.ietf.org/tools/idnits/ and
the Internet-Drafts Checklist).  Boilerplate checks are not
enough; this check needs to be thorough.

Some nits. Will be fixed during/after IETF LC if necessary.

(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?

Not yet.

(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.

None.

(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.

No.

(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).

IANA section is fine. Might want to register two
company-allocated OIDs somewhere later, but that's
not an IANA registry afaik.

(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.

N/A.

(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.

Will send IETF LC announcement to TLS WG for checking.