466488 - Changes to Country handling in Identity UI

Status: NEW

(Firefox :: Security, defect, P3)

Description

[Johnathan Nightingale [:johnath]]

Recently Thawte issued a certificate under their EV root which did not specify a C= field in the Subject section of the certificate (instead, it used the subject:jurisdictionOfIncorporationCountryName OID 1.3.6.1.4.1.311.60.2.1.3).  I believe this is permissible under the CABForum guidelines, but it's also quite unusual.

It exposes two considerations for our UI, though:

1) We should check for both C= and 'OID.1.3.6.1.4.1.311.60.2.1.3'= when determining country code

2) We should change the existing code which quietly drops the (CA) country code string, to instead say something like (??) when neither is present, to make problematic certificates more discoverable to their issuers/consumers.

http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#6539

Comment 1

[Johnathan Nightingale [:johnath]]

Until it is changed, the site presenting this cert is located at:

https://domain.ficora.fi/fidomain/aca.aspx

Kai, do you agree with this approach?

Comment 2

[Eddy Nigg (StartCom)]

Johnat, the C field (OID 2.5.4.6) is optional in EV certs but jurisdictionOfIncorporationCountryName (OID
1.3.6.1.4.1.311.60.2.1.3) MUST be present in the certificate. There can't be a case where neither is present, it would be a violation of the EV guidelines. Actually for EV certs you should only check for jurisdictionOfIncorporationCountryName.

Comment 3

[Johnathan Nightingale [:johnath]]

Attachment: Check for both the shorthand (L, ST, C) and longhand OIDs for location information

Comment 4

[Kaspar]

(In reply to comment #0)
> Recently Thawte issued a certificate under their EV root which did not specify
> a C= field in the Subject section of the certificate (instead, it used the
> subject:jurisdictionOfIncorporationCountryName OID 1.3.6.1.4.1.311.60.2.1.3). 
> I believe this is permissible under the CABForum guidelines, but it's also
> quite unusual.

(In reply to comment #2)
> Johnat, the C field (OID 2.5.4.6) is optional in EV certs but
> jurisdictionOfIncorporationCountryName (OID
> 1.3.6.1.4.1.311.60.2.1.3) MUST be present in the certificate.

In my reading/understanding of the EV guidelines, this is not permissible. Specifically, section 6(a)(6), "Physical Address of Place of Business", states:

"Required/Optional: City, state, and country - Required; Street and postal code
- Optional"

It has always been required, even in Draft 11, which was in force at the time the cert for domain.ficora.fi was issued (7th June 2007). I think this case falls under item (7) of the "Revocation Events" in the EV Guidelines, so it needs to be replaced - should Jay Schiavo be added to the Cc?

> Actually for EV certs you should only check for jurisdictionOfIncorporationCountryName.

Depends on whether the country label should indicate the place of business or the jurisdiction of incorporation/registration.

Comment 5

[Johnathan Nightingale [:johnath]]

(In reply to comment #2)
> Johnat, the C field (OID 2.5.4.6) is optional in EV certs but
> jurisdictionOfIncorporationCountryName (OID
> 1.3.6.1.4.1.311.60.2.1.3) MUST be present in the certificate. There can't be a
> case where neither is present, it would be a violation of the EV guidelines.
> Actually for EV certs you should only check for
> jurisdictionOfIncorporationCountryName.

But virtually all EV certs *do* include it, so I think saying "use either C or OID1.3...3" is still a pretty acceptable practice. I don't think a CA should have any cause to issue an EV cert in which those values differed, for instance, and in the case where they match, it doesn't matter which one we use.

I do think it argues for just fixing the code though, not the string.  I don't think there should be any EV cert out there which fails to specify both of these things, and I don't think it justifies adding a late string to deal with the eventuality.  I guess we could file a follow-up...

And yeah, I will copy Jay Schiavo on this, although I know he's already aware of the issue.

Comment 6

[Eddy Nigg (StartCom)]

(In reply to comment #4)
> "Required/Optional: City, state, and country - Required; Street and postal code
> - Optional"
> 

Yeah, right! The presentation in the EV Guidelines is a little bit unlucky.

Comment 7

[Kai Engert [:KaiE:]]

I guess they have already updated the cert, the site mentioned in comment 1 now uses a cert carrying a C field, issued today. It might be helpful for testing if someone made a backup of the server cert.

Comment 8

[Kai Engert [:KaiE:]]

What UI did you get when there was no C field? Something like
  ()
?

I don't know whether your "string_a | string_b" works correctly when string_a is a zero length string. I don't know whether a zero length string gets converted to a boolean false expression. I would personally prefer a test that is more intuitive to read, that explicitly refers to the length of the strings. I don't know whether you also must test for the "undefined" state.

Whether falling back to those OID fields seems to be a policy decision. I am adding Frank, Nelson and Bob to the cc list, I believe they have more knowledge to say whether those fields are good to display.

In other words, Johnathan proposes:
- if subject C is missing, try to display OID.1.3.6.1.4.1.311.60.2.1.3
- if subject ST is missing, try to display OID.1.3.6.1.4.1.311.60.2.1.2
- if subject L is missing, try to display OID.1.3.6.1.4.1.311.60.2.1.1


Another concern I have with your proposal:
You are changing Firefox specific code. I'm sure there are other places in our core code that try to display those fields, for example in the cert viewer. Do you have arguments why your changes should be done only for the identity UI, but not in other locations?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

The new cert's subject name differs in a number of ways from the old one.
Going from imperfect memory here, IIRC, the old cert subject contained
these OIDs, among others:
L
ST
OID.1.3.6.1.4.1.311.60.2.1.1
OID.1.3.6.1.4.1.311.60.2.1.2
OID.1.3.6.1.4.1.311.60.2.1.3

The new one contains these (among others)
L
ST
C
OID.1.3.6.1.4.1.311.60.2.1.3

(In reply to comment #8)
> What UI did you get when there was no C field? Something like
>   ()
> ?

Yesterday, Larry's UI was showing 

 <Locality>
 <State>

Today it is showing

 <Locality>
 <State>, <Country>

The state value is different today than before.  

> Whether falling back to those OID fields seems to be a policy decision. I am
> adding Frank, Nelson and Bob to the cc list, I believe they have more 
> knowledge to say whether those fields are good to display.
> 
> In other words, Johnathan proposes:
> - if subject C is missing, try to display OID.1.3.6.1.4.1.311.60.2.1.3
> - if subject ST is missing, try to display OID.1.3.6.1.4.1.311.60.2.1.2
> - if subject L is missing, try to display OID.1.3.6.1.4.1.311.60.2.1.1

IIRC, the CABForum's EV guidelines define a number of subject name attributes
for which they set down minimum requirements for verification by the CA.
The implication (apparently) is that any not listed are not verified according
to any standard set by CABForum and may not be verified at all (e.g. OU).

IMO, Larry should only show those fields for which CABForum has set minimum
verification "guidelines".  I think it's reasonable for Larry to show ALL 
of that info.  I have no objection to showing the "country of incorporation"
if the ordinary Country is missing.  Better yet, show both.  Maybe UI like:

Location
  <Locality>
  <State>, <Country>
Incorporated in
  <Locality>
  <State>, <Country>

If that's unacceptable, then showing the Incorporation as an alternative 
to the physical location is probably an acceptable substitution.  
It might be meaningful to the user to know that the country code given is
not the location, but rather the place of incorporation, especially if 
they're different.  So, I think the UI should show something to show that
the substituted attribute is different from the normal one.

As an aside: IIRC, PSM has a table of OIDs and OID name strings that it uses
to supplement NSS's own list for purposes of showing nice strings in the cert
viewer dialog.  I recommend that strings be added to that table for the 3 
Microsoft OIDs cited above, ASAP.

Comment 10

[Eddy Nigg (StartCom)]

(In reply to comment #9)
> IMO, Larry should only show those fields for which CABForum has set minimum
> verification "guidelines".  I think it's reasonable for Larry to show ALL 
> of that info.  I have no objection to showing the "country of incorporation"
> if the ordinary Country is missing.  Better yet, show both.  Maybe UI like:
> 
> Location
>   <Locality>
>   <State>, <Country>
> Incorporated in
>   <Locality>
>   <State>, <Country>
> 

+1

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 349765 [details] [diff] [review]
Check for both the shorthand (L, ST, C) and longhand OIDs for location information

This request is ancient, and I don't even know if there's still a benefit to taking this, but the patch seems to still apply!

r=me for the code-style, anyhow (to address Kai's concern from comment 8).

Comment 12

[Johnathan Nightingale [:johnath]]

Still worth taking, I think. Still needs kaie's review, though.

Comment 13

[Kai Engert [:KaiE:]]

Comment on attachment 349765 [details] [diff] [review]
Check for both the shorthand (L, ST, C) and longhand OIDs for location information

If you all agree these are the right fields (and alternative fields) to display, I'm fine with the patch.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:sgalich, could you have a look please?
For more information, please visit auto_nag documentation.