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

["David A. Cooper" <[e-mail]>]

I think it's fine for browsers to check for syntactic errors in 
certificates. However, I interpreted "thorough syntactic checks on 
certificates" to mean that browsers should be performing checks such as 
the ones described in 
https://tools.ietf.org/html/draft-kent-trans-domain-validation-cert-checks 
and 
https://tools.ietf.org/html/draft-kent-trans-extended-validation-cert-checks.

Most of the checks in these drafts are fine, as they are checks for 
requirements that are unlikely to change. However, some of the checks 
are more problematic. For example, the first of these drafts say that 
for DV certificates

             if the [subject] name does not contain an organizationName 
attribute,
             then the streetAddress attribute MUST NOT be present. If
             the organizationName attribute is present, the streetAddress
             attribute MAY be present.  This requirement is derived from
             section 9.2.4b of [CABF-DV].

What if a browser implemented a check for this and then the CA/Browser 
Forum later updated their Baseline Requirements to allow a streetAddress 
attribute in the subject fields of certificates that do not contain an 
organizationName attribute? This wouldn't cause a problem for users who 
keep their browsers up to date, but some clients continue to use 
browsers that are very old.


Section 5.6 says that the Monitor needs to obtain a list of certificates 
for the Subject to use as a reference, and then it says that "A Monitor 
must not rely on certificate discovery mechanisms to build the list of 
valid certificates since such mechanisms might result in bogus or 
erroneous certificates being added to the list." The phrase "or 
erroneous" should be removed.

There is no risk if the Monitor adds an erroneous certificate (that is 
not bogus) to the list of valid certificates, as it will not not mean 
"that the monitor would fail to alert the Subject about an erroneous 
certificate." If a Monitor is going to perform syntactic checks on 
certificates, then it should check all certificates for syntactic 
errors, regardless of how they came into its possession, even 
certificates that are received from the Subject in a secure manner for 
the purpose of creating a reference list of non-bogus certificates.

On 05/07/2018 03:56 PM, Andrew Ayer wrote:
> On Fri, 4 May 2018 14:51:47 -0400
> "David A. Cooper" <[e-mail]> wrote:
>
>> Section 4.1.1.4 says "Unfortunately, experience suggests that many
>> browsers do not perform thorough syntactic checks on certificates, and so
>> it seems unlikely that browsers will be a reliable way to detect erroneous
>> certificates." and Section 4.2.1.4 says "As noted above (4.1.1.4), most
>> browsers fail to perform thorough syntax checks on certificates." These
>> sentences should be removed or modified. There is no reason that a
>> browser should perform thorough syntactic checks on certificates, and
>> there are good reasons for browsers not to. So, this document should
>> not be labeling this as unfortunate or a failure. We do not want to
>> encourage browsers to perform thorough syntax checks on certificates, as
>> this could lead to the same types of problems that TLS has experienced,
>> where making a change in something causes deployed products to break.
> The trend in Firefox and Chrome is to make their certificate validators
> much stricter about "syntactic" errors.  I think the main point of
> section 4.1.1.4 is that it's not feasible for browsers to notify other
> parties when it detects a syntactically misissued certificate, so these
> checks need to be performed by monitors.
>
> I think this sentence should just be dropped, as it's not true anymore
> and tries to moralize about a controversial issue.
>
>> Section 5.6, paragraph 4 says that "A Monitor must not rely on certificate
>> discovery mechanisms to build the list of valid certificates since such
>> mechanisms might result in bogus or erroneous certificates being added
>> to the list." What would be the risk if an erroneous certificate was
>> added to the list? When a Monitor is obtaining a list of certificates
>> for the Subject to be monitored, wouldn't we want erroneous certificates
>> to be included in that list so that the Monitor has a chance to detect
>> the error?
> Monitors look for subject names, not specific certificates.  The list
> of valid certificates is so the monitor doesn't raise an alarm when it
> finds a legitimate certificate for a monitored subject name.
>
> So the answer to your first question is that the monitor would fail
> to alert the Subject about an erroneous certificate.  This could be
> clarified in section 5.6.
>
> The answer to your second question is that the monitor would still
> detect erroneous certificates, because it's monitoring based on subject
> name.  This seems to be clear already from the description of a monitor
> in the introduction.
>
> Regards,
> Andrew
>