Closed Bug 1432181 Opened 2 years ago Closed 10 months ago

Remove BR BRNameMatchingPolicy::FallBackToCommonName (Ignore X.509 CommonName field in favor of SubjectAlternativeName/SAN for the WebPKI)

Categories

(Core :: Security: PSM, enhancement, P3)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jcj, Assigned: dipen)

References

(Blocks 1 open bug)

Details

(Whiteboard: [psm-deprecation] [psm-contractor])

Chrome is disabling name matching for the CommonName field [1]. The SubjectAlternativeName field has been required in all Web PKI certificates since v1.0 of the Baseline Requirements (1 July 2012) [2], making the CommonName field a now-5.5-year-old backward compatibility mechanism.

Certificates that do not include a SAN field have become very rare on the public Internet.

We should remove this backward-compatibility mechanism when possible.

[1] https://twitter.com/sleevi_/status/955454614354235392
[2] https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1.pdf
Correction: This should be specifically to remove the fallback logic [1] which is now stale.

[1] https://searchfox.org/mozilla-central/source/security/certverifier/BRNameMatchingPolicy.cpp
Summary: Ignore X.509 CommonName field in favor of SubjectAlternativeName/SAN for the WebPKI → Remove BR BRNameMatchingPolicy::FallBackToCommonName (Ignore X.509 CommonName field in favor of SubjectAlternativeName/SAN for the WebPKI)
Right now, as you see from the code you linked to, Firefox allows CN fallback for older certs.  Changing the security.pki.name_matching_mode pref to 3 enforces no fallback (the current default is set to 1).  This pref does not affect imported roots which always allow fallback (see my request below).

So, what you are really asking is for them to change the default from 1 to 3.  Personally, I'm OK with that, particularly in the nightly and DE builds just to get some feedback.

However, I have a request as well.  Allow this to be enforced for imported roots as well (or at least provide a preference to enforce it).  I know enterprises have been lax in following RFC 2818 and not providing SANs in their certs, but a little pain is good to get things moving (again, a toggle pref is good for this).  As mentioned, Chrome is now enforcing this for imported roots, so enterprises are experiencing this issue already.
Pushed by jjones@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/644cb19702ca
Revert spurious npm-shrinkwrap.json changes r=me CLOSED TREE
(In reply to Pulsebot from comment #3)
> Pushed by jjones@mozilla.com:
> https://hg.mozilla.org/integration/mozilla-inbound/rev/644cb19702ca
> Revert spurious npm-shrinkwrap.json changes r=me CLOSED TREE

Ugh, wrong bug ID in that. Oh well; marking this leave-open. For anyone coming to check out this bug from that push, that should have been for Bug 1441338.
Keywords: leave-open
Blocks: 1461370
Blocks: 1461373
Blocks: 1463936
Whiteboard: [psm-deprecation]
Dipen, can you add this to your to-do list?
Assignee: nobody → bugzilla
Status: NEW → ASSIGNED
Keywords: leave-open
Whiteboard: [psm-deprecation] → [psm-deprecation] [psm-contractor]
Currently the default for security.pki.name_matching_mode pref is set to 3 which enforces no fallback.

I understand the scope to remove BRNameMatchingPolicy::FallBackToCommonName method and always assume FallBackToSearchWithinSubject::No where it was called.

Do we want to go further and clean up all logic surrounding fallback to common name?  For example removing fallBackToCommonName parameter to SearchNames(), SearchWithinRDN(), MatchAVA() functions.
Flags: needinfo?(jjones)
Mmmm. Probably, but keeping in mind Bug 1461370 wants to support this fallback mechanism only for imported roots (e.g., enterprise cases). I am guessing due to that bug we wouldn't want to actually remove a bunch of this code, just change how it triggers (and add a new preference).

I may well be wrong though! I haven't dug into it closely.
Flags: needinfo?(jjones)

We probably don't want to remove the ability to configure this just yet, so let's wontfix this for now.

Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.