372980 - XPInstall reports "(Author not verified)" when signing certificate has no organization subject

Status: RESOLVED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Sean Leonard]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

XPInstall reports that an extension is "Unsigned" when the signed extension does not have an organization O= value in the certificate subject. This is a problem for all kinds of extension developers who are individuals, since individuals usually can get individual codesigning certificates in their own names (CNs) only, without organizational names (Os).

Sample xpi packages and png images illustrating the problem are available at the URL above.

Reproducible: Always

Steps to Reproduce:
1. Lay out an xpi package with appropriate folder structure (see <http://www.mozilla.org/projects/xpinstall/signed/testcases/>.)

2. Sign with a codesigning certificate that does not contain O=, but does contain other parameters like CN and E. The easiest way is to use the signtool command in nss tools:
signtool -d "certificate directory" -k "cert nickname" -p "password" -X -Z "file.xpi" directory-tree

3. Confirm the signature with signtool -w.
I ran:
signtool -d . -w noorgsigned.xpi
using certificate directory: .

Signer information:

nickname: NoOrgCert
subject name: CN=Common Name with No Org,E=[e-mail]
issuer name: CN=Common Name with No Org,E=[e-mail]

4. Drag and drop or otherwise attempt to install into a Mozilla application, such as Firefox.
Actual Results:  
The top-right corner says Unsigned in bold red text.

Expected Results:  
The top-right corner should say something else indicating that the .xpi was signed.

After a partial review of the relevant code, the best temporary fix would be to compute the relevant name using the following pseudocode.

if signed {
if O is present in signed certificate, use O
else if CN and E are present in signed certificate, use CN <E>
else if CN is present in signed certificate, use CN
else if E is present in signed certificate, use E (or <E>)
else if any subject is present in signed certificate, use the entire Subject line
else use "Signed without Identification"
} else use empty string ""

A more permanent fix would:
1) put the appropriate string "Signed without Identification" (or "Signed but Unidentified") in a localized string bundle
2) allow the user to inspect the certificate in the installation UI
3) actually verify the signed package before presenting the installation prompt the user, and indicate whether the package is "Signed but Invalid" (or "Invalid Signature") in the installation UI
4) include a tooltip over the name of the signer, including other relevant information from the certificate

See the following code references:

http://lxr.mozilla.org/seamonkey/source/xpinstall/res/content/institems.js#55
http://lxr.mozilla.org/seamonkey/source/xpinstall/res/content/institems.js#94

http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsXPITriggerInfo.cpp#169

http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsXPInstallManager.cpp#299

I am not quite sure which of these is computing the name from the certificate, but "aPrincipal->GetPrettyName(prettyName);" in nsXPITriggerInfo.cpp#169 is a good starting point.

Comment 1

[Serge Gautherie (:sgautherie)]

Which product/version are you using ?

Can you reproduce with SeaMonkey v1.1.9 ?

Comment 2

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.15pre) Gecko/2008052503 BonEcho/2.0.0.15pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)

Report "Unsigned" :-(
{{
/toolkit/locales/en-US/chrome/global/xpinstall/xpinstall.properties
    * line 95 -- Unsigned=Unsigned
}}

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008052406 Minefield/3.0pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008052902 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Report "Author not verified" :-)
{{
/toolkit/locales/en-US/chrome/mozapps/xpinstall/xpinstallConfirm.properties
    * line 1 -- unverified=(Author not verified)
}}

R.WontFix, as this would be a string change on branch.

Comment 3

[Daniel Veditz [:dveditz]]

Serge: please don't make WONTFIX decisions without discussing with the module's owners/peers. This is clearly not the intent of the dialog and is a valid bug. It wouldn't require string changes if we used the string provided by the cert so that's not necessarily a valid concern, and even if string changes are required the trunk suffers from the same problem (wordage change from 'unsigned' to "author unverified" is purely cosmetic).

Comment 4

[Wladimir Palant]

I've run into this issue as well now, got a code signing certificate from StartCom:

E=[e-mail],CN=Wladimir Palant,OU=StartCom Verified Certificate Member,L=Koeln,ST=Nordrhein-Westfalen,C=DE

This is a personal certificate, hence no organization name - and rather than falling back to the CN entry Firefox simply reports "Author not verified". Unfortunately, this has the result of leaving extension signing to Google & Co. while excluding most extension authors.

Comment 5

[Wladimir Palant]

The code responsible can be found in nsXPITriggerItem::SetPrincipal:

    if (hasCert) {
        nsCAutoString prettyName;
        // XXXbz should this really be using the prettyName?  Perhaps
        // it wants to get the subjectName or nsIX509Cert and display
        // it sanely?
        aPrincipal->GetPrettyName(prettyName);
        CopyUTF8toUTF16(prettyName, mCertName);
    }

The point Boris makes here shouldn't be hard to fix...

Comment 6

[Wladimir Palant]

Attachment: Possible patch

Using nsIX509Cert to get the CN entry from the certificate, only using prettyName as fallback. This works correctly for signed Adblock Plus build, the results for Google Toolbar and Yahoo Toolbar didn't change. However, I cannot really understand from bug 240661 comment 25 whether this is an acceptable solution, hope Boris can tell that.

Comment 7

[Eddy Nigg (StartCom)]

According to Microsoft, code singing certificates which don't have the organization validated should not set any value for the organization field. The correct behavior should be to display the common name field (always).

There wouldn't be a problem from our point of view and existing policies to publish the personal name in the organization field if there wouldn't be a compatibility issue with Microsoft policies. Effectively StartCom is adjusting its updated policies and practices to that affect.

Comment 8

[Boris Zbarsky [:bzbarsky]]

So... this string is just meant to be a nice human-readable identifier.  Should we just change nsNSSComponent::VerifySignature to either use CN in preference to O or to use CN as fallback if O is not set?

ccing some folks who (unlike me) actually understand this stuff.

Comment 9

[Eddy Nigg (StartCom)]

Actually the CN field for code signing might be even more important than the O field. It's certainly how we see it as a CA. On the other hand having a strong organization behind the identity is also a good indication. In any case both instances are valid. Nelson, Johnath, your comments please?

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #8)
> So... this string is just meant to be a nice human-readable identifier. 

Agreed, so 
Q1) IS it really relevant to determining that the code is properly signed? 
and if so,
Q2) WHY?

Comment 11

[Wladimir Palant]

> Q1) IS it really relevant to determining that the code is properly signed?

No, for that you verify that the certificate is valid, the name on the certificate is irrelevant.

> Q2) WHY?

My understanding is that the information "this extension has been signed with a valid certificate" carries too little value for most users. This message seeks to create a trust relationship - "look, we can tell who created this extension, do you want to trust this guy?"

Comment 12

[Wladimir Palant]

I found a Windows executable where CN and O entries don't match: http://www.nigelpentland.co.uk/racf/racf.exe. Verified that the Windows warning "Do you want to run that file" displays the CN entry as publisher, same goes for "Name of signer" in signature details and "Issued to" in certificate view. You have to dig pretty deep to see the organization name at all ("personal" in this case). I guess that pretty much sums up Microsoft's opinion on what should be displayed to the user.

Comment 13

[Wladimir Palant]

And a Java applet: https://netbank.danskebank.dk/html/index.html?site=DBNB&secsystem=E2
This page asks for two applets to run. The one with publisher "Danske Bank Group" has subject "CN=Danske Bank Group, OU=Java Software Code Signing, O=Sun Microsystems Inc" (Sun Microsystems???). So it seems that Java also displays the common name to users rather than the organization name.

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

My questions in comment 10 were intended to be socratic.  
Now, I'll be more direct.

There is NO requirement that a code signing cert contain ANY one particular 
name attribute (such as CN, or O, or OU) to be valid.  A code signing cert 
should work, even if it has no CN, or no O.  Microsoft may say otherwise, 
but that's of no concern to FF.  

The essence of Sean's (the reporter's) complaint is not that the O is not 
displayed, but rather is that FF 2.0 said the XPI was unsigned.  He surmised
and asserted that FF2 said it was unsigned because the cert subject name contained no O attribute.  I doubt that is the real explanation.  But, if he 
is right, and FF reports an XPI is unsigned because it lacks an O or a CN, 
that's a bug in FF, pure and simple.  

The solution is not to display some other field than the O, because the 
problem is NOT fundamentally the name that is DISPLAYED, but rather is that 
Firefox says it is unsigned.  The solution is to make FF say it is signed,
not to make it display a different name.

Now, it may be (and I suspect it is) the case that FF 2.0 reported Sean's XPI 
file as unsigned for some other reason, having nothing to do with the absence
of the O attribute.  I think it is likely that the missing O attribute is 
purely coincidental.  Unfortunately, no sample XPI was ever provided with 
which FF and NSS developers could ever debug the problem.  I think this bug
will never be fixed while that remains the case.  

I'm inclinded to mark this bug RESOLVED/INCOMPLETE until we have a 
reproducible test case, with which it can be proven that the missing O 
attribute is really the cause of FF saying it is unsigned.

Comment 15

[Sean Leonard]

Hello.

Finally we get some action on this bug after two years. :)

Nelson is basically correct. The original bug is not concerned so much with which part of the distinguished name was displayed: it is concerned that a missing O causes Firefox to report the XPI is not signed at all.

The URL provided as the main URL of this bug is still working (surprisingly, perhaps) after two years. Try to click on the XPIs--you will see the same behavior in Firefox 3, and I suppose in Firefox 3.5 as well (I have tried Firefox 3.0.11 but not Fx 3.5). The XPIs at that URL have been there all along since March 6, 2007.

In Firefox 3.0.11, it reports "(Author not verified)" in the XPI install window. I will add an attachment PNG image, but you are welcome to verify the same for yourself.

Comment 16

[Sean Leonard]

Attachment: Image of author not verified when O is missing

Comment 17

[Sean Leonard]

As to the matter of what should be displayed to the user:

The matter of what string should be displayed to the user was not the original thrust of the bug. However, there's some discussion about this, so I thought I would address with some high-level points.

What is displayed to the user is ultimately up to whoever--or whatever organization--is authoring the code that parses the digital certificate information. I presume that would be MoCo in the case of XULRunner applications. Nevertheless, there are three guideposts:
a) what the standards say,
b) how certification authorities interpret the standards when they issue X.509/PKIX digital certificates (which may not comply with the standards), and
c) how various pieces of deployed software interpret the standards when they parse X.509/PKIX digital certificates (which may not comply with the standards).

Comment #14 from Nelson suggests that what other pieces of software (aka c) ) do is irrelevant from the standpoint of Mozilla. That's fine by me. However, you may still wish to deal with the fact that every version prior to (and probably including) Fx 3.5 shows the O field only.

As to the standards, there's no substitute for the original standards text:
RFC 5280
[See http://tools.ietf.org/html/rfc5280 ]
4.1.2.4. Issuer

4.1.2.6. Subject
   The subject field identifies the entity associated with the public
   key stored in the subject public key field.  The subject name MAY be
   carried in the subject field and/or the subjectAltName extension.  
...
   If subject
   naming information is present only in the subjectAltName extension
   (e.g., a key bound only to an email address or URI), then the subject
   name MUST be an empty sequence and the subjectAltName extension MUST
   be critical.

   Where it is non-empty, the subject field MUST contain an X.500
   distinguished name (DN).
...
   The subject field is defined as the X.501 type Name.  Implementation
   requirements for this field are those defined for the issuer field
   (Section 4.1.2.4).  Implementations of this specification MUST be
   prepared to receive subject names containing the attribute types
   required for the issuer field.  Implementations of this specification
   SHOULD be prepared to receive subject names containing the
   recommended attribute types for the issuer field.
...

Going now to subject names in the issuer field:
   Standard sets of attributes have been defined in the X.500 series of
   specifications [X.520].  Implementations of this specification MUST
   be prepared to receive the following standard attribute types in
   issuer and subject (Section 4.1.2.6) names:

      * country,
      * organization,
      * organizational unit,
      * distinguished name qualifier,
      * state or province name,
      * common name (e.g., "Susan Housley"), and
      * serial number.

Similar text appears in RFC 3280.

Okay, so that answers that question. Now then, what does X.520 say? X.520 (2005) says exactly this:

5.2 Labelling attribute types
These attributes type are concerned with information about objects which has been explicitly associated with the objects
by a labelling process.

...

5.2.2 Common Name
The Common Name attribute type specifies an identifier of an object. A Common Name is not a directory name; it is a (possibly ambiguous) name by which the object is commonly known in some limited scope (such as an organization) and
conforms to the naming conventions of the country or culture with which it is associated.
An attribute value for common name is a string chosen either by the person or organization it describes or the
organization responsible for the object it describes for devices and application entities. For example, a typical name of a
person in an English-speaking country comprises a personal title (e.g., Mr., Ms., Rd, Professor, Sir, Lord), a first name,
middle name(s), last name, generation qualifier (if any, e.g., Jr.) and decorations and awards (if any, e.g., QC).
Examples
CN = "Mr. Robin Lachlan McLeod BSc(Hons) CEng MIEE";
CN = "Divisional Coordination Committee";
CN = "High Speed Modem".
Any variants should be associated with the named object as separate and alternative attribute values.

Other common variants should also be admitted, e.g., use of a middle name as a preferred first name; use of "Bill" in
place of "William", etc.

5.2.8 DN Qualifier
The DN Qualifier attribute type specifies disambiguating information to add to the relative distinguished name of an
entry. It is intended to be used for entries held in multiple DSAs which would otherwise have the same name, and that its
value be the same in a given DSA for all entries to which this information has been added.

5.2.9 Serial Number
The Serial Number attribute type specifies an identifier, the serial number of an object.
An attribute value for Serial Number is a printable string.

5.3 Geographical Attribute Types
These attribute types are concerned with geographical positions or regions with which objects are associated.

5.3.1 Country Name
The Country Name attribute type specifies a country. When used as a component of a directory name, it identifies the
country in which the named object is physically located or with which it is associated in some other important way.
An attribute value for country name is a string chosen from ISO 3166.

5.3.3 State or Province Name
The State or Province Name attribute type specifies a state or province. When used as a component of a directory name,
it identifies a geographical subdivision in which the named object is physically located or with which it is associated in
some other important way.
An attribute value for State or Province Name is a string, e.g., S = "Ohio".

5.4 Organizational attribute types
These attribute types are concerned with organizations and can be used to describe objects in terms of organizations with
which they are associated.

5.4.1 Organization Name
The Organization Name attribute type specifies an organization. When used as a component of a directory name it
identifies an organization with which the named object is affiliated.
An attribute value for OrganizationName is a string chosen by the organization (e.g., O = "Scottish Telecommunications
plc"). Any variants should be associated with the named Organization as separate and alternative attribute values.

[NOTE: skipping "Collective Organization Name"]

5.4.2 Organizational Unit Name
The Organizational Unit Name attribute type specifies an organizational unit. When used as a component of a directory
name it identifies an organizational unit with which the named object is affiliated.
The designated organizational unit is understood to be part of an organization designated by an organizationName
attribute. It follows that if an Organizational Unit Name attribute is used in a directory name, it shall be associated with
an organizationName attribute.
An attribute value for Organizational Unit Name is a string chosen by the organization of which it is part (e.g., OU =
"Technology Division"). Note that the commonly used abbreviation "TD" would be a separate and alternative attribute
value.

[NOTE: skipping "Collective Organizational Unit Name"]

END X.520 (2005)
*********

All this is to say that O, when interpreted in accordance with the X.520 standard, means: "When used as a component of a directory name it
identifies an organization with which the named object is affiliated." CN, when interpreted in accordance with the X.520 standard, means: "a (possibly ambiguous) name by which the object is commonly known in some limited scope (such as an organization) and conforms to the naming conventions of the country or culture with which it is associated."

It appears that the X.520 (2005) authors did not explicitly address the issue of what happens when a certificate is issued to a whole organization, which is ironic given the dominant use cases of X.509 certificates on the Internet. I would simply resolve this tension by interpreting CN as being "the organization name" in such cases, when another de-facto standard (aka legacy SSL's use of CN for DNS hostnames) does not dominate. One could equally resolve this tension by considering an organization to be "affiliated with itself," so using O is not a problem either. However, one would want some basis that the named entity in the Subject field is not only "affiliated with" O--the named entity in the Subject field is in fact O, nothing more or less.

The only other standards-based guidepost we have is RFC 5280 4.1.2.6. itself, which says: "The subject field identifies the entity associated with the public key stored in the subject public key field." A perfectly valid interpretation of this sentence would suggest that the user should see the whole subject field, possibly represented in RFC 1485/RFC 1779 form. I would argue against this interpretation, however, because it is not user-friendly. It also does not deal with the sticky subject of the Subject field vs. subjectAltName.

Whether any particular certification authority issues certificates that conform to the X.520 and RFC 5280 definitions, is up to that CA to decide. However, a CA will likely tend to issue certificates in a way that causes software that uses the CA as a trust anchor to display the "right thing" in context.

Comment 18

[Johnathan Nightingale [:johnath]]

I think it's appropriate to fall back to CN when O is not available - it's also consistent with the UI we present for websites. I'm not sure I'd prefer CN over O, if only because most certs will either have only one, or have them very closely matching (Wladimir's find in comment 12 notwithstanding) and preferring O over CN means no surprising change for existing signed addons.

As for Nelson's point that this is really about whether the cert is recognized as signed at all, and not so much about what is displayed - I think the structure of the dialog confounds the two. When the dialog is initialized, it checks its arguments to see if it was provided with an org name (confusingly labelled "cert" even though it appears to be a plaintext string!):

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js#80

What it's being populated with comes from xpinstall code, where the manager is init'd:

http://mxr.mozilla.org/mozilla-central/source/xpinstall/src/nsXPInstallManager.cpp#221

which, after some wandering via CertReader, ends up here:

http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsNSSComponent.cpp#1982

where it uses orgname (only) as the pretty name, when creating a cert principal.

So to sum up: the code to check whether an app is signed all makes its way through properly afaict (yay), but the string displayed in the UI doesn't really reflect that, since it looks only for orgname and, failing to have one, displays the "(Author not verified)" text.  

In that sense, then, this *is* a display issue, and I think we should fix it. And if, as Nelson points out is possible, we encounter XPIs which are properly cryptographically signed but do not supply an O *or* a CN field, we'll go through the standard signature verification, but we will present a UI saying the author isn't verified because it isn't verified in a way which is useful for users making that decision. A signature from an unknown party does not meaningfully help users make their trust decision. Fixing Sean's problem of individuals whose code signing certs don't include O fields but do include CN fields does help users make that decision.

Comment 19

[Wladimir Palant]

Johnathan, more context for comment 12 - I went through lots of executables to find one (!) that had a difference between organization and common name. It seems that most CAs have a policy of verifying organizations and setting common name to the same value (I've seen it mentioned for Thawte at the very least). Even the few executables that were signed by personal certificates had that person's name listed as organization. So I wouldn't expect major changes by switching from organization name to common name or vice versa.

However, for the two examples (executable and applet) where I did find a difference between organization name and common name the organization name was pretty useless or even misleading, the certificate authorities issuing these certificates certainly didn't mean the organization name to be the most significant string displayed to users. So while I agree that it is probably best to keep displaying the organization on branches and use CN as fallback, it might be worth considering to reverse the logic on trunk. As mentioned above, the standards give no real hints here so we can only base the decision on common practice (which is likely based on what Microsoft and Sun are doing rather than what Mozilla is doing).

Comment 20

[Wladimir Palant]

Oh, and having a link to view certificate from the install confirmation dialog (thus allowing the user to see the entire subject field) would be a nice to have of course - but definitely outside the scope of this bug.

Comment 21

[Dave Townsend [:mossop]]

(In reply to comment #20)
> Oh, and having a link to view certificate from the install confirmation dialog
> (thus allowing the user to see the entire subject field) would be a nice to
> have of course - but definitely outside the scope of this bug.

bug 278629

Comment 22

[Dave Townsend [:mossop]]

Comment on attachment 386858 [details] [diff] [review]
Possible patch

As it stands this patch causes 6 test failures in the xpinstall tests so those would have to be fixed. There is also matching code in nsExtensionManager.js.in that would need to be corrected.

Comment 23

[Eddy Nigg (StartCom)]

I agree with Wladimir that the CN field should have priority over the O field. I think that would align FF with other implementations which would be beneficial.

Comment 24

[Nelson Bolyard (seldom reads bugmail)]

I would suggest and recommend that the browser stop trying to guess which
of the name attributes is most important and/or more relevant, and display
the ENTIRE subject name in string form.  I'm talking about the 
CN=foo,OU=bar,O=zzz,L=YYY,C=XXX form, which is available.  

There are countries that have no laws barring businesses from using the same
names as other well-known businesses.  For example, one could imagine getting 
a cert that reads: O=Mozilla Corporation,C=CN   In such a case, the O name
by itself is not the only or (necessarily) most important feature of the name.

In reply to Johnathan's comment 18, I would point out that Sean's original
complaint was about the presence of the word "Unsigned" in some dialog. 
In comment 4, Wladimir added the issue of the "Author not verified" string.
It may be that these two problems have the same underlying cause, and that
it is the cert name string, but I'd be surprised by that.  IMO, for *this* 
bug to be considered "fixed", the "Unsigned" string issue MUST be resolved.

Comment 25

[Dave Townsend [:mossop]]

(In reply to comment #24)
> I would suggest and recommend that the browser stop trying to guess which
> of the name attributes is most important and/or more relevant, and display
> the ENTIRE subject name in string form.  I'm talking about the 
> CN=foo,OU=bar,O=zzz,L=YYY,C=XXX form, which is available.

This really is completely unhelpful for the average user I think. We might as well just say it is signed without any additional information.

> In reply to Johnathan's comment 18, I would point out that Sean's original
> complaint was about the presence of the word "Unsigned" in some dialog. 
> In comment 4, Wladimir added the issue of the "Author not verified" string.
> It may be that these two problems have the same underlying cause, and that
> it is the cert name string, but I'd be surprised by that.  IMO, for *this* 
> bug to be considered "fixed", the "Unsigned" string issue MUST be resolved.

"Unsigned" and "Author not verified" are the same indicators, we just changed the string in Firefox 3.0.

Comment 26

[Eddy Nigg (StartCom)]

Dave, what's in your drivers license? Lets have a look...

Your Name
Address
State - Zip - Locality
(Country)

Now, what so unhelpful the user can't understand with that? That's how I would send a letter to you. Nothing exotic really...no XYZ hash, encryption babble, technical stuff...

Comment 27

[Dave Townsend [:mossop]]

(In reply to comment #26)
> Dave, what's in your drivers license? Lets have a look...
> 
> Your Name
> Address
> State - Zip - Locality
> (Country)
> 
> Now, what so unhelpful the user can't understand with that? That's how I would
> send a letter to you. Nothing exotic really...no XYZ hash, encryption babble,
> technical stuff...

I was commenting on the understanding that Nelson actually meant literally the string in the form "CN=foo,OU=bar,O=zzz,L=YYY,C=XXX". What can I say, it's late.

Comment 28

[Eddy Nigg (StartCom)]

Well, yes....Nelson can't think out of X.509 schema, you must forgive him...that's why we have such an expert at hand :-)

Comment 29

[Nelson Bolyard (seldom reads bugmail)]

OK, I was lazy.  How about this:
> CN=Dave Townsend,OU=Add Ons,O=Mozilla Corporation,L=Mountain View,ST=California,C=US  

Or alternatively, displayed attribute by attribute:

CN=Dave Townsend,
OU=Add Ons,
 O=Mozilla Corporation,
 L=Mountain View,
ST=California,
 C=US  

(I actually have no idea where on Earth you are, Dave :)

Comment 30

[Eddy Nigg (StartCom)]

LOL...as I said...Nelson has his ways, but we can display this nicely in a way it makes sense for our users, right? :-)

Just - I think OU isn't that useful if we need to manage space efficiently.

Comment 31

[Boris Zbarsky [:bzbarsky]]

So for my last $0.02 on this bug (and hopefully on this whole topic), it sounds to me like we should:

1) Change what prettyName is in certificates (probably to be both CN and O in
   some order?) ASAP so as to allow personal signing certs to produce reasonable
   UI here at all.  This needs a change in the PSM code mentioned in comment 18.
2) Change the UI here to differentiate between "signature not verified" and
   "signed by someone, but I can't tell who", if that's a distinction that makes
   sense here.
3) Design a sane "identity" display for certificates that would actually make
   sense to the average user and make it easy to hook up that display to a
   given nsIX509Cert or nsIPrincipal.

This should be happening in at least 3 separate bugs; I would make the change in item 1 in this bug and spin off separate bugs (if we don't have one for item 3 already) on the other issues.

Comment 32

[Johnathan Nightingale [:johnath]]

(In reply to comment #25)
> (In reply to comment #24)
> > I would suggest and recommend that the browser stop trying to guess which
> > of the name attributes is most important and/or more relevant, and display
> > the ENTIRE subject name in string form.  I'm talking about the 
> > CN=foo,OU=bar,O=zzz,L=YYY,C=XXX form, which is available.
> 
> This really is completely unhelpful for the average user I think. We might as
> well just say it is signed without any additional information.

It's our job to figure out what to present to users that will be helpful to them, without being confusing. So while I recognize Nelson's desire to eliminate the guesswork, I'm not going to agree with a string that includes x.509 field identifiers, and am not particularly keen to include all the fields, even without identifiers. Our cert policy for code signing certs requires more than we do of DV SSL CAs, but even still I don't feel like treating all of those fields as verified truth.

I agree with almost everything Boris said - we can make a small, helpful change here around using CNs - let's do that. Other work (including the continuing temptation we all feel to completely rejigger the signed addon UI) should live in other places.

My only reason for preferring O over CN was precedent, and the case has been made that precedent tips more strongly the other way; so be it. Who feels like writing the patch I describe in comment 18 and boris revisits in comment 31, part 1? We get an incremental improvement there that I think is relatively undisputed.

Comment 33

[Dave Townsend [:mossop]]

(In reply to comment #32)
> My only reason for preferring O over CN was precedent, and the case has been
> made that precedent tips more strongly the other way; so be it. Who feels like
> writing the patch I describe in comment 18 and boris revisits in comment 31,
> part 1? We get an incremental improvement there that I think is relatively
> undisputed.

If Wladimir doesn't want to take this then I'll do it. Can we just be clear on what we're looking for. From what you say I read this is changing the prettyName attribute to return the CN if there is one or O if not. Or did you want to try for some combination like Boris suggests (this would I suspect cause localisation complications)?

Comment 34

[Johnathan Nightingale [:johnath]]

(In reply to comment #33)
> (In reply to comment #32)
> > My only reason for preferring O over CN was precedent, and the case has been
> > made that precedent tips more strongly the other way; so be it. Who feels like
> > writing the patch I describe in comment 18 and boris revisits in comment 31,
> > part 1? We get an incremental improvement there that I think is relatively
> > undisputed.
> 
> If Wladimir doesn't want to take this then I'll do it. Can we just be clear on
> what we're looking for. From what you say I read this is changing the
> prettyName attribute to return the CN if there is one or O if not. Or did you
> want to try for some combination like Boris suggests (this would I suspect
> cause localisation complications)?

I mean:

prettyName = CN || O

basically. I don't know if Boris' #2 would be helpful (what good is the attestation, if you don't know who's attesting?) and while #3 feels more and more like a thing we might need, it's well out of scope for this bug, I'd argue. Let's do the straightforward, smarter thing here and now.

Wladimir - should we assign this to you, or is it not really your cup of tea?

Comment 35

[Eddy Nigg (StartCom)]

Looking at the attached patch, isn't this exactly what you want?

Comment 36

[Dave Townsend [:mossop]]

(In reply to comment #35)
> Looking at the attached patch, isn't this exactly what you want?

That changes just the xpinstall case, Boris is suggesting we should change what prettyName actually means everywhere. Having skimmed over other uses I can see places were we would certainly want to make this change to keep things consistent, however it is certainly a more invasive change to change it everywhere.

Comment 37

[Eddy Nigg (StartCom)]

IMO, this is not what Johnath and others suggested. The current "fix" should be for code-signing only. Changing the order for server certificates is not suggested.

Comment 38

[Wladimir Palant]

I'll try to get a patch for this today or tomorrow. Thanks for getting that patch back into a state where something can be done about it.

Comment 39

[Steffen Wilberg]

Tweaking subject to mention the "(Author not verified)" string we actually use since Firefox 3.0, see comment 25 and 
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/xpinstall/content/xpinstallConfirm.js#83
http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/mozapps/xpinstall/xpinstallConfirm.properties#1

Comment 40

[Dave Townsend [:mossop]]

(In reply to comment #38)
> I'll try to get a patch for this today or tomorrow. Thanks for getting that
> patch back into a state where something can be done about it.

Wladimir, do you still have time to finish this up? If not I can probably take it on.

Comment 41

[Wladimir Palant]

Sorry, I forgot to update the status here. Yes, please take over.

Comment 42

[Dave Townsend [:mossop]]

Attachment: patch rev 1

This is a low impact patch, it just touches the installation of extension XPIs. It won't affect scripts in signed jars, not sure if we need to touch there or not.

This patch simply uses the CN if it has some content or the current prettyName if not (which translates to O). Updated all the appropriate testcases and added test xpis that only have O or only have CN set in their signers.

Comment 43

[Daniel Veditz [:dveditz]]

Comment on attachment 395052 [details] [diff] [review]
patch rev 1

r=dveditz

Comment 44

[Dave Townsend [:mossop]]

I'm not likely to get chance to land this till next week

Comment 45

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/814cff28021c

Comment 46

[Dave Townsend [:mossop]]

On branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/9356c9127b96

Comment 47

[Eddy Nigg (StartCom)]

Fantastic! Is there a chance this gets back-ported to the current branch?

Comment 48

[Dave Townsend [:mossop]]

Attachment: 1.9.1 branch patch

(In reply to comment #47)
> Fantastic! Is there a chance this gets back-ported to the current branch?

We're just waiting on the approval for the 1.9.1 branch. I've just noticed that the patch doesn't apply cleanly there though. This is a version that does, it just has some of the changes removed that aren't necessary there because bug 386153 was never fixed there.

Comment 49

[Daniel Veditz [:dveditz]]

Comment on attachment 404865 [details] [diff] [review]
1.9.1 branch patch

Approved for 1.9.1.5, a=dveditz for release-drivers

Comment 50

[Dave Townsend [:mossop]]

Landed on 1.9.1 branch: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2f9a687a93f1

Comment 51

[Dave Townsend [:mossop]]

Also followup fixes because my brain doesn't seem to be working right today:

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/3314ecd0f55a
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/5c7d314437ca
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/490df273c928

Comment 52

[Al Billings [:abillings - ex-MoCo]]

Does anyone have an extension available that displays this problem so it can be used for a manual verification of the fix?

Comment 53

[Wladimir Palant]

Attachment: Signed Adblock Plus development build

Here is one - it currently shows "author not verified" in Firefox 3.5.5 and "Wladimir Palant" in Minefield. I guess I can switch on signing for Adblock Plus development builds again...

Comment 54

[Eddy Nigg (StartCom)]

Attachment: Image of Installation Prompt

Is this the expected result?

Comment 55

[Al Billings [:abillings - ex-MoCo]]

Yes, Eddy, that's the expected result.

I just compared 1.9.1.5 with my 1.9.1.6 build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6pre) Gecko/20091119 Shiretoko/3.5.6pre (.NET CLR 3.5.30729)) and this is clearly fixed in the new builds.

Thanks, Wladimir!

Comment 56

[geateazr]

Sorry if reviving this bug is inappropriate, but I'm hit by this again with Firefox 33.0 (current Ubuntu version). Please feel free to delete this post if this is indeed not upstream related.

When I try to install the add-on DownThemAll v2.0.17 (https://addons.mozilla.org/en-US/firefox/addon/201/), Firefox tells me "(Author not verified)". The package is correctly signed though, but the certificate is lacking an O= entry.

Expected behaviour: According to the discussion above, the CN= entry should be shown.

Comment 57

[geateazr]

Ehm, sorry for the inconvenience. The issue is resolved. The certificate had expired. signtool seems not to bother, Firefox does. I thought it would not due to the discussion in bug 298664. Well.. if possible please delete my posts to cleanup this thread again.