On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote: > You mean EKU-constrained (e.g. to email, or OCSP only)?
I was thinking also of a pathlen constraint. Suppose I am able to cause an automated system to issue me arbitrary SHA-1 signed certificates from a particular CA, at least once, and I plan to use this with a chosen plaintext attack to produce a certificate of my choosing: With no constraints I get a CA:TRUE certificate and can issue anything I want. This is a more or less a worst case scenario. With just an S/MIME EKU set, I can get a CA:TRUE certificate but it only lets me spoof any email address (by creating certificates chaining through my fake CA:TRUE intermediate). A disaster for S/MIME, but for 90% of the world it's not even a problem. With just CA pathlen:0, I can make any one end-entity certificate from my attack. Probably the most valuable thing I can make is a wildcard TLS cert for a major domain that doesn't use key-pinning. Bad, to be sure, but very clearly limited in scope. With both an S/MIME EKU set and CA pathlen:0 I am reduced to making one fake S/MIME email certificate for each successful attack. > > Another economic tactic would be to require CAs to use long random > > serial numbers even in non-BR certificates. > > How long would you say is long enough? I would propose the same length which is currently required in the BRs for new TLS certificates, and let CAs bargain you down within reason if there is some technical obstacle which prevents them meeting this. As with the constraints idea, the purpose of this rule is to make the expected attack uneconomic and thus dissuade anyone from even trying. Without knowing how much bad guys think such certificates could be worth, nor how much it would cost them to attempt the attack I can't offer even a finger in the air estimate, only observe that more is better. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
