The stated goal was to be *less* onerous than Kathleens proposal, which
was the the CRL issuer DN should be encoded exactly as it is in *every*
certificate referring to that issuer.
For the majority of CAs where this was always the case, neither
requirement would do involve any action at all. For the cases where a
CA has in the past issued certificates and CRLs with different IssuerDN
encoding, but has done so consistently, my proposal would allow the CA
to end its problematic practice without having to roll a new
intermediary CA with a different CRL service URL.
For the third case (which may or may not be as common as the second
one) where a CA has in the past issued certificates and CRLs with
different IssuerDN encoding, but has already mended its ways so more
recently issued certificates have the same IssuerDN encoding as in the
CAcert and CRL, the original proposal would have required *the same
CRL* to contain two conflicting IssuerDN encodings while my proposal
would allow such a CA to simply make a public statement that this is
the situation (with some specific details) and then continue.
>
> Put differently, there is a considerably high bar for requiring CAs take
> some action - or answer a particular question. Making sure it's clear why
> can help evaluate the value of what you propose, otherwise it's very easy
> to dismiss such suggestions as random non sequitors.
>
>>
>> The data is minimal and compact, unlike CT logs.
>
>
> For example, this appears as a nonsequitor, because no one has proposed
> sending CT logs to clients (the contextual way to read this suggestion,
> given the statement that follows). Another way to read it (ignoring what
> follows) suggests perhaps confusion between a CT log (which clients don't
> download) and an SCT (which is minimal and compact for what it is). Or it
> could be read that you're suggesting someone simply comb the CT logs,
> extract the CRL URLs, and compare those against the issuer fields present.
I was indeed suggesting the impracticality of both these causes of
action.
>
> While it seems highly unlikely you're proposing the last option, given your
> expressed disdain and occasional confusion about CT, I mention it because
> it's example of where the data can be independently obtained, rather than
> using the threat of force (which is, implicitly, what is behind every CA
> communication - the threat of removal), and arguably in a way that more
> accurately captures practical impact.
>
> The complete dataset
>> from all public CAs combined is likely to be just a few kilobytes
>> uncompressed, much less compressed.
>
>
>>
>> Potentially, this same table as a substitute for fuzzy mapping can also
>> be used when building/following certificate chains.
>
>
> Right, so just to follow:
>
> You're proposing that, rather than list it as a problematic practice for an
> edge case from a few CAs, Mozilla use a CA communication - possibly with a
> change to the Baseline Requirements - so that they can write additional
> code that no other client implements and ship several kilobytes (at least)
> of data and code.
No, I am suggesting that while *still* listing it as a problematic
practice for an edge case from a few few CAs, Mozilla offers those few
CAs an easier way out, while at the same time obtaining for both itself
and any other implementors (such as Google's BoringSSL and Microsoft's
CNG) a table of the only values that code for that edge case will need
to handle.
I was also suggesting, that if, after gathering data, the resulting
table is very small, using the table in code might be easier than
coding an algorithm that matches certificates to issuers and CRLs for
all the needed non-identical cases. This however would be an
implementation choice, as any other algorithm giving correct results
would solve the problem.
>
> It does seem like Kathleen's current proposal is far more reasonable, and
> so no, your proposal does not seem like a proper set of rules.
>