Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis

[Ryan Sleevi <[e-mail]>]

On Tue, May 15, 2018 at 10:50 AM, David A. Cooper <[e-mail]>
wrote:

> I can't speak for Steve, but I can provide an example of a syntax error I
> encountered as a result of "quirks of CA certificate-issuing software."
>
> Many years ago when I was tasked to check whether certificates being
> issued by a CA were being issued in conformance with the appropriate
> profile, I discovered that the keyUsage extensions in the certificates were
> not DER encoded. The contents of the extension were correct according to
> BER, but not DER, and everything else about the certificate was correct.
>
> This must have been the fault of the developer of the CA software and not
> the company operating the CA. This would not be a security or trust failure
> by the CA and most clients wouldn't even notice the problem. There would,
> however, be the risk that some client software somewhere would not accept
> the certificate simply because of the encoding problem, so it was useful
> for the encoding problem to be identified and fixed.
>

I think we may disagree on this assessment. I agree that it presents an
interoperability issue - but I think a failure of the CA to actually ensure
that their software conforms to the profile is a grounds for concern. We've
seen a spectrum of CAs and competencies - and I know of some CAs that have
expressly written tools to ensure everything they issue conforms to the
appropriate profile (i.e. they actually understand their systems) versus
CAs that think that if you use some COTS product, you've got Production
Grade issuance.

CT very much cares about detecting these issues, in practice, and in fact,
it's the detection, discovery, and mitigation of precisely these sorts of
issues that have demonstrated the most immediate practical value. Further,
because of the existence of such linting tools, CAs are now expected to run
such linting tools prior to their issuance.

It is thus, to that end, that having logs reject such certificates (i.e.
logs as linters) that would undermine the development of and enforcement of
issuance policy. Linting-as-a-service is provided by separable endpoints,
and while such services can mask the underlying issues that CAs have,
that's conversely part of the goal of having such APIs - to check a
tbsCertificate before the CA has actually signed the material, while
checking a precertificate/certificate means that the CA has actually signed
it, and is notable for detection and censure.