On 21/04/2017 21:29, Nick Lamb wrote:
On Tuesday, 18 April 2017 18:33:29 UTC+1, Jakob Bohm wrote:
I believe the point was to check the prospective contents of the
TBSCertificate *before* CT logging (noting that Ryan Sleevi has been
violently insisting that failing to do that shall be punished as
harshly as actual misissuance) and *before* certificate signing.
I come to this as always as someone focused on prevention of future harm. I can't speak for Ryan
but I'm not interested in "punishing" anybody because retribution does not avoid future
harm in itself. For example distrust of a CA is not a "punishment" of that CA, but a step
taken to protect relying parties from certificates which shouldn't exist.
Detecting already bad situations still counts as prevention of future harm,
this is because almost always the bad situation might get worse if undetected.
This is why we fit smoke alarms - it would be bad if my flat was on fire, but
it would be much worse if in the absence of an alarm it simply burned down with
me inside it.
If some CA comes to m.d.s.policy twice a year with a problem where a
certificate was issued that shouldn't have been, but they've cured it and
altered their systems so that won't happen again - I can't say I'm ecstatic to
see that, but at least they're paying attention.
In contrast if they're here twice a year because an independent researcher
found a year-old certificate that shouldn't exist, and Gerv has to ask them for
comment, then they investigate what went wrong and promise to cure it, I have
to say I look on that much less kindly, and I suspect Ryan does too.
I wrote this in the context of your previous post about why this
prevention code would have the ability to accidentally alter the
certificate before it was signed. My point was to explain, in
general, why such code is forced to run before signing and in a
context where preventing the checking code from altering the
certificate has a (small but) non-zero cost, unlike a check done
after issuance and/or after CT submission.
As for Ryan, I think his own response was quite illustrative.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
