[cabfpub] SHA1 options for payment processors

Ryan Sleevi sleevi at google.com
Mon Mar 14 07:29:41 MST 2016


On Mar 13, 2016 4:41 PM, "kirk_hall at trendmicro.com" <
kirk_hall at trendmicro.com> wrote:
>

> Dean has proposed a general procedure with objective criteria by which a
CA may issue SHA-1 certs that expire by Dec. 31, 2016, and which is
intended to ensure that these interim SHA-1 certs will NOT be trusted by
any of the browsers (and which includes some fairly ingenious methods for
ensuring they will not be trusted).

Regrettably, this is not true, which is why we are still having this
conversation, although I appreciate that you find the browser-proposed
alternatives to Dean's original request for blanket issuance ingenious.
Every method Dean proposed, for example, does NOT ensure they will not be
trusted - and as such, puts profound risk on the Internet at large.

If such risk is to be accepted, a meaningful discussion how to mitigate
that risk is a prerequisite. It is simply brazenly unacceptable to suggest
that the risk is equal for all participants, or that a one size fits all
approach takes into consideration the needs of anyone but the CA and their
customers. I appreciate your view that the risk is acceptable, but this is
not a shared view.

> In fact, this creates greater user security than if the customers managed
to purchase one year SHA-1 certs on Dec. 31, 2015, which they could have
done, so already Dean’s proposal is an improvement on the existing security
situation for SHA-1 certs.

This is so logically flawed and factually wrong that I am uncertain on how
to respond. It would be truly disappointing if you believe that allowing
new issuance of SHA-1 creates less or no risk than the alternatives.

> Dean’s draft criteria included some objective business and technical
requirements similar to what we already have for BR 6.3.2, which carves out
limited, objective  circumstances under which a CA can issue a 60-month DV
or OV cert instead of limiting the cert to 39 months (basically, BR 6.3.2
requires the CA to confirm that the customer has a legacy app that will
fail with a cert of less than 60 months validity period and where there is
no known security risk to Relying Parties, etc.).   That is a very good
approach to a situation like this.

I strongly disagree - which is why there is a ballot proceeding right now
to remove it. To the best of my knowledge, only a single CA argued for this
exception, and only a single CA used this exception, and that CA is the
same one requesting more exceptions today. There may have been more, I
admit, but that too highlights why such things are bad - because such
general exceptions make it hard to balance or quantify the scope. Further,
as you may be unaware from the debate and discussion regarding this ballot
to remove that exception, because it was so broadly worded, there is no
understanding about the scope or even need for it, in the general sense.

But most importantly, and seemingly, most obviously, both the exceptions
(direct issuance from root and a long-lived cert) do not directly put the
entire Internet at risk, nor does it create risk for all participants in
the ecosystem. A long-lived cert affects only the named domain holder, and
direct issuance from the root is an operational risk of bringing a root key
online that is similarly mitgatable via appropriate procedures. These are
both vastly different in scale and impact than the proposal before us.

> Early in this discussion, someone made a comment along the lines of “I
don’t want to approve any general criteria for allowing these interim,
untrusted SHA-1 certs, instead I want to approve such certs on a
case-by-case basis for each and every applicant, who must make its case to
me.”  I think that’s a really bad approach.

Well, if you are going to summarize me, you could at least have the
courtesy to do it accurately. Luckily, as this debate is happening
publicly, it is easy to point back to my past messages in the archive to
demonstrate easily and obviously that this is not what I said, nor is your
characterization accurate. Which is part of the point - this is a public
debate being held about the need for a public debate, and when someone so
clearly misconstrues an argument, it is easier to point to fact and what
was actually said than to haggle over the recollection of what was said in
a proverbially smoky room or private phone call.

Given the nature of your further remarks, I find it unlikely to provide
further value to reiterate the points I made earlier on the value of both
public debate (for the ecosystem AND for the Forum), other than to
highlight that the argument is already laid out, and rather than refute it
or address it, you've chosen to mischaracterize it. As such, I can't really
respond - because you're no longer making a thoughtful argument to a
nuanced debate, but seemingly a straw man that you can tear down.

If you do take the time to revisit the past responses, from me and others,
you will see your questions have already been answered as to "Why?", and if
you have trouble understanding them or you disagree, I think it's entirely
reasonable to ask that you just say that. I'm sure I and others would be
happy to explain to you further, and would be happy to address your
criticisms on their merits.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160314/adf349e7/attachment-0001.html 


More information about the Public mailing list