On 18/04/2017 18:47, Nick Lamb wrote:
Hi Jeremy
Given the small number of certificates involved, it might make sense to just
convert them to text and mention them inline, or put them somewhere we can all
see them - if it's inconvenient to put them into the CT logs.
I think this situation will be useful as evidence of the value of not putting
all ones eggs in one basket when it comes to subCA EKUs. If these had come from
a subCA which wasn't constrained, we'd have a bigger (though at five specific
certificates still manageable) issue.
On Tuesday, 18 April 2017 17:10:39 UTC+1, Jeremy Rowley wrote:
The bug was introduced, ironically, in code we deployed to detect potential
errors in cert profiles. This error caused the specified code signing
certificates to think they needed dNSnames and serverAuth. Let me know if
you have questions.
This irony might perhaps have been avoided if the code in question didn't have
permission (never mind intent) to alter anything. I appreciate that what one
would ideally like is to never issue a bad certificate, and to achieve that any
checks must happen in a trusted part of the system. But it seems to me that
there's a good deal of benefit, at practically zero risk, in building tooling
that focuses on monitoring stuff which has already been signed, outside of the
protected signing environment; and only subsequently after proving it there
giving it the earlier, more powerful (and thus risky) role.
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.
Thus the checks would have to occur before signing, but it would still
be useful (architecturally) to run the checks without the ability to
change the request (other than to reject it with an error message).
Such separation will however have non-zero cost as the prospective
TBSCertificate or its description needs to be passed between additional
processes.
Of course I know nothing of your specific circumstances, this is just a general
observation about how I think I'd approach the question of improving issuance
quality with minimal risk.
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
