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" <[email protected]> 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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
