[Servercert-wg] Browser Alignment Ballot - Name Chaining

[Ryan Sleevi]

On Thu, May 14, 2020 at 12:21 PM Corey Bonnell <CBonnell at securetrust.com>
wrote:

> > I'm open to suggestions you feel would be useful here to clarify. I
> disagree that it's possible to escape the potentially messy comparison
> logic because the only way you can be sure that a CA is not using said
> logic is to, well, depend on said logic to say for what you MUST NOT do.
>
>
>
> I think a requirement that mandates that the Issuer Name for all
> associated artifacts (certificates, CRLs, and OCSP) be byte-to-byte
> identical with the subject DN in the CA Certificate without referencing RFC
> 5280 section 7.1 -- which does not provide the desired result due to
> deviations in RFC 4518 compliance by UAs and carries with it significant
> complexity -- would largely accomplish the goals that you outlined.
>

The problem with this approach is that it still permits:
1) Two different issuing CA certificates to use different encodings, and
thus Subject certificates to use encodings that are consistent with one
issuer (e.g. A) but not the other issuer (e.g. A'). This seems the far more
likely cause of misinterpretation/misissuance.
2) An argument that the aforementioned CAs (A and A') are somehow different
Issuers

I totally considered the approach you're using, and the problem is that
it's got enough loopholes and ambiguities that it fails to solve any of the
problems.

That's where and why the reference to Section 7.1 is necessary; it's
necessary to define what constitutes an equivalent issuer that should be
byte-for-byte identical, and exactly where and why we've seen CAs have
issues.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200514/b51513e1/attachment.html>