<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 26, 2017 at 2:40 PM, Bruce Morton <span dir="ltr"><<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div class="m_-3415387907373392058WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I will try to think up some use cases as this doesn’t come up that often. I am not saying that these are applicable to Entrust. However, I do know that since
 we need to support many clients and browsers which are continually changing and updating policies, there is a chance that a CA may need some maintenance for best browser ubiquity.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">So some use cases could be certificate expiry, lengthen CA lifetime, add in AIA, mistakenly sign the certificate with the wrong hash, mistakenly sign the certificate
 with the wrong pathlength, sign the CA by a different CA, etc.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Please note we have always supported CNs in subordinate CAs. Our software does not support unique CNs for subordinate CA certificates.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I am also open to discuss bad results and security issues, but am hoping we can discuss those as a separate discussion.</span></p></div></div></blockquote><div><br></div><div>I think they're sort of related. Obviously, the goal with what I hope is most (all?) of our work here is to improve security and continue to make meaningful progress. At the same time, understandably, this can result in breakage - from incomplete knowledge of the use cases, from unanticipated side effects, etc. So we have to balance the costs and the benefits here, and especially if we want to try to find a solution that works for everyone's needs, we have to get a good solution.</div><div><br></div><div>Of the things you mentioned, I don't think lengthening the CA lifetime is a valid case, but again, I could be misunderstanding. All the certificates issued under the CA should be constrained to its lifetime, and since 'extending' requires signing something new anyways, and this would/should have no impact on the existing certs, then signing with a new name shouldn't cause any issues.</div><div><br></div><div>Wrong Hash is interesting, because that suggests a failure in the Key Signing Ceremony script. That is, I would think those would be carefully audited and reviewed prior to performing. It's also something that shouldn't be done once an intermediate is out there - this actually caused a _lot_ of unnecessary pain in the SHA-1 deprecation, because of CAs having multiple certificates with the same name. I'm not trying to throw stones here - Google's GIA G2 suffered this same problem, and regardless of who is to blame for signing with the wrong algorithm, it happened, and it's caused real pain for both Google and, as I understand it, Microsoft.</div><div><br></div><div>Signing the certificate with the 'wrong' path length is a good example of imbuing extra capabilities into an existing tree (which is bad, I think) or restricting the capabilities too late (which is also bad, because th eother cert is out there). Revocation doesn't really help here - I know of at least two Browser Members here for which revocation is done after path construction is 'completed', and as a result, if you have two intermediates with the same name, different pathLengths, with one revoked and one not, you can end up preventing access. Similar to wrong hash, this hopefully captures why changing names is good.</div><div><br></div><div>I think you did touch on an interesting point though - there are some changes which don't imbue extra capabilities or change the semantics. Adding an AIA with caIssuers, for example, is sort of a no-op optimization. In theory, so is adding an AKID. But others - like an AIA for an OCSP responder or changing the CRL DP - really does have semantic impact on the cert. So there's a spectrum here, and I think we should try to understand this use case more, and see if it's not better addressed by better ceremonies and normative requirements, rather than adding after the fact. Once a cert is out there, we are sort of stuck with the hand we're dealt, and that's why Google's so keen on seeing a reduction in the certificate lifetimes (which we'll be announcing soon our plans for), because while it may not be obvious, reducing the _leaf_ certificate lifetime helps improve _intermediate_ agility.</div><div><br></div><div>So that leaves the last case - cross-signs. And cross-signs are a complex beast that, done incorrectly, can significantly impair the security of users unnecessary. I know of several Member CA's cross-signs that have resulted in security issues for either relying parties or operational issues for browser members trying to scope appropriately, and I absolutely think we need better guidance here. That's not to say this ballot is meant to solve that issue now, so if that's the only blocker/concern here, maybe we can find the right language to satisfy this.</div></div></div></div>