On 22/05/17 16:43, Matthew Hardeman wrote: > Regarding specifically the risk of the holder of a technically > constrained subCA issuing a certificate with an SHA-1 signature or > other improper signature / algorithm, my belief at this time is that > with respect to the web PKI, we should be able to rely upon the > modern client software to exclude these certificates from > functioning. My understanding was that IE / Edge was the last > holdout on that front but that it now distrusts SHA-1 signatures.
So your proposal is that technical requirements should be enforced in-product rather than in-policy, and so effectively there's no need for policy for the EE certs under a TCSC. This is not an unreasonable position. > How do the various validation routines in the field today validate a > scenario in which a leaf certificate's validity period exceeds a > validity period constraint upon the chosen trust path? Is the > certificate treated as trusted, but only to the extent that the > present time is within the most restrictive view of the validity > period in the chain, or is the certificate treated as invalid > regardless for failure to fully conform to the technical policy > constraints promulgated by the chain? Good question. I think the former, but Ryan Sleevi might have more info, because I seem to remember him discussing this scenario and its compat constraints recently. Either way, it's a bad idea, because the net effect is that your cert suddenly stops working before the end date in it, and so you are likely to be caught short. > I submit, then, that the real questions become further analysis and > feedback of the risk(s) followed by specification and guidance on > what specific constraints would form up the certificate profile which > would have the reduced CP/CPS, audit, and disclosure burdens. As a > further exercise, it seems likely that to truly create a market in > which an offering of this nature from CAs would grow in prevalence, > someone would need to carry the torch to see such guidance (or at > least the relevant portions) make way into the baseline requirements > and other root programs. Is that a reasonable assessment? Well, it wouldn't necessarily need to make its way into other places. Although that's always nice. Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
