[cabfpub] [EXTERNAL]Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

[Ryan Sleevi]

On Wed, Apr 26, 2017 at 2:40 PM, Bruce Morton <
Bruce.Morton at entrustdatacard.com> wrote:

> 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.
>
>
>
> 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.
>
>
>
> Please note we have always supported CNs in subordinate CAs. Our software
> does not support unique CNs for subordinate CA certificates.
>
>
>
> I am also open to discuss bad results and security issues, but am hoping
> we can discuss those as a separate discussion.
>

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.

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.

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170426/0f05451a/attachment-0003.html>