Re: Last Call: <draft-hallambaker-tlsfeature-09.txt> (X.509v3 TLS Feature Extension) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]