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

Tue, 15 May 2018 07:51:32 -0700

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.

It's not clear, however, that this is the type of error draft-ietf-trans-threat-analysis has in mind. Section 1 of the document says:

   A certificate is characterized as syntactically mis-issued (aka
   erroneous) if it violates syntax constraints associated with the
   class of certificate that it purports to represent.  Syntax
   constraints for certificates are established by certificate profiles,
   and typically are application-specific.

Similarly, https://tools.ietf.org/html/draft-kent-trans-domain-validation-cert-checks makes no mention of encoding errors, such as the one I encountered.

But, my guess would be that syntactic mis-issuance was intended to include encoding errors in addition to violations of application-specific certificate profiles.

NOTE: I have no position of which entity, if any, should be checking for these types of errors, or on how the discovery of such errors should be handled if they are found.

On 05/14/2018 10:06 PM, Ryan Sleevi wrote:
 
Page 20 says that "syntactic checking [of pre-certificates] by a log helps avoid issuance of an erroneous certificate." This is contrary to RFC6962 and RFC6962-bis, which both state that issuing a pre-certificate is a binding commitment by the CA to issue a certificate. It would be dangerous for a CA to follow the advice on page 20, as browsers rightly consider misissuance of a pre-certificate to be equivalent to misissuance of a real certificate.

I'll change the text on page 20 to state that a log could help a CA detect and avoid issuing a syntactically erroneous cert. Also, what 6962 says is not relevant here- that was an experimental doc, not standards track. Submission of a pre-cert to a log probably does indicate an internet to issue a cert, but certificate issuance need not result in delivery to a Subject. If a CA were advised by a log that a certificate was malformed (e.g.., due to “quirks of CA certificate-issuing software” then the CA could ditch the certificate, or revoke it, and try again.

I don't think that would be a positive change, and have to agree with Andrew here, that it would seem moreso detrimental to the ecosystem that CT aims to improve.

I'm not sure the rationale for ditching the certificate is at all reasonable - the fact that such a certificate was even considered as 'log worthy' by a CA is a demonstration of a failure by that CA to uphold public trust. In that model, it's vitally essential for the Log to make that known - not to help the CA cover it up. In this regard, that the CA has used its key to sign something - anything - that fails the checks is a demonstration of risk to any PKI that trust this CAs.

I think painting it as quirks does a disservice - it's an operational failure of the CA, and thus, by proxy, a security and trust failure by the CA. That is, if anything, one of the most noteworthy events - rather than the inverse.
 
CAs must perform syntactic checks on the TBSCertificate prior to signing anything.

In principle yes, but in practice, … “quirks of CA certificate-issuing software”

I'm not sure what you're referring to as quirks again. This is a rather fatal failure mode, and one of the express goals of 6962 (and, through proxy, 6962-bis) is to detect and publicize any CA with such quirks, such that relying parties can move to distrust or otherwise restrict such CAs.

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

Reply via email to