Wording for last paragraph of Section 2, bottom of page 3:
----------------------------------------------------------
The inclusion of a TLS feature extension advertising the
status_request feature in the server end entity certificate permits a
client to fail immediately if the certificate status information is
not provided by the server.
Suggestion: s/server end entity certificate/server end-entity certificate/
Section 2 top of page 4:
------------------------
Since the TLS feature extension is an option, it is not likely that
an attacker attempting to obtain a certificate through fraud will
choose to have a certificate issued with this extension. Such risks
are more appropriately addressed by mechanisms such as Certification
Authority Authorization DNS records RFC 6844 [RFC6844] that are
designed to prevent or mitigate mis-issue.
I'm profoundly disappointed that the CAB forum seems to have fumbled
CAA support by adopting a weasel-out option:
https://cabforum.org/2014/10/14/ballot-125-caa-records/
Support for CAA was not made mandatory, and so, for now, CAA is a
failure. Without CAA (and an agreement between the legitimate CA
and its customer that all certifiates shall signal required OCSP
stapling) the protocol proposed by this draft addresses only key
compromise and not fraudulently obtained certificates (from some
other CA with the fraudster as customer).
Even if CAA records were effective, and the fraudster had to deal
with the subject's preferred CA, what would prevent the issuance
of an "exception" certificate without mandatory OCSP stapling?
Surely an attacked skilled enough in social-engineering to obtain
an unauthorized certificate will be able to persuade the CA that
a new product that must urgently be deployed does not yet support
OCSP stapling,
This is acknowledged in Section 5.1:
Use of the TLS feature extension to mandate support for a particular
form of revocation checking is optional. This control can provide
protection in the case that a certificate with a TLS feature is
compromised after issue but not in the case that the attacker obtains
an unmarked certificate from an issuer through fraud.
The TLS feature extension is a post-issue security control. Such
risks can only be addressed by security controls that take effect
before issue.
The phrase "Such risks" above is I think not sufficiently strongly
bound to the preceding text to make it clear that it is referring
to the "but not ..." part of the last sentence of the previous
paragraph.
--
Viktor.