Closed Bug 740571 Opened 13 years ago Closed 11 years ago

Improve PSM's assertion about WebSite Owner if cert Policy OID has 2.23.140.1.2.2

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: kathleen.a.wilson, Unassigned)

Details

For certs with the Policy OID 2.23.140.1.2.2, PSM should assert the website owner is the SSL cert's Subject "O". CA/Browser Forum BR 9.3.1: "The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting compliance with these Requirements as follows: ... (2.23.140.1.2.2), if the Certificate complies with these Requirements and includes Subject Identity Information that is verified in accordance with Section 11.2. If the Certificate asserts the policy identifier of 2.23.140.1.2.2, then it MUST also include organizationName, localityName, stateOrProvinceName (if applicable), and countryName in the Subject field." Example... Browse to https://bugzilla.mozilla.org Click on the blue bar at the top, where it says mozilla.org. The popup says "You are connected to mozilla.org which is run by (unknown)" Click on "More Information" In "Website Identity" it says Owner: This website does not supply ownership information. The certificate Subject field has "O = Mozilla Corporation" PSM could be improved so that if the certificate also had Policy OID 2.23.140.1.2.2, then "Mozilla Corporation" could be displayed instead of "unknown".
Kathleen, do you propose that "Owner: This website does not supply ownership information" should be changed too?
(In reply to Rob Stradling from comment #1) > Kathleen, do you propose that "Owner: This website does not supply ownership > information" should be changed too? Yes
Great. Do you agree that "does not supply ownership information" is a misleading statement for both BR-quality OV and traditional "OV" certificates that contains the O= field?
I think pre-BR populated Organization fields are problematic. But if the purpose is to remove that phrase from the UI, that's fine. If the purpose is to include some information, then it should be only for BR compliant certificates.
If OID 2.23.140.1.2.2 is present, the locality and other address info should be displayed as well. If OID 2.23.140.1.2.1 is present, the cert is "Domain control only validated", and it's appropriate to say that the domain has been validated. If one of the EV OIDs is present, the current EV handling applies. If none of the above, the current "does not supply ownership information" remains appropriate. These rules become mandatory for new certs on July 12, 2012. Old certs will still be valid until they expire. Ref: "http://www.cabforum.org/Baseline_Requirements_V1.pdf". All this is part of an effort to tighten up cert issuance after the DigiNotar and TrustWave debacles. As a technical note, it should be noted that the way this data is stored is weird. An SSL cert is a tree structure, much like JSON, expressed in ASN1 binary format. The certificatePolicies field (OID of 2.5.29.32), though, doesn't have its contents defined in RFC2527. It usually is an object of type OctetString, ASN1's container for uninterpreted bytes. As used in EV certificates, as defined by the CA/Browser Forum, those bytes are another level of ASN1 data, and have to be extracted as bytes, then run through an DER ASN1 decoder to get a tree just for the certificatePolicies field. The format of that tree is not well defined. I'm encouraging the CA/Browser Forum to add a technical appendix to their document to define the exact format used. Mozilla should probably be prepared to find there any of an OctetString, which can be treated as ASN1, a PrintableString (legacy, for display only) or more levels of objects in the current ASN1 tree. Also, when traversing this subtree, there may be multiple levels of ASN1 Tuple and Sequence objects encapsulating the OIDs of interest. OID values, incidentally, can be looked up at the OID repository at "oid-info.com". This is a mess because the CA/Browser Forum didn't coordinate with the IETF and X.509 when they put that info in there. Once you know the above, though, it's not hard to implement.
(In reply to John Nagle from comment #5) <snip> > If none of the above, the current "does not supply ownership information" > remains appropriate. Strongly disagree. If the O= field is present in a website's certificate (even if it's a self-signed certificate!), then that site *is* supplying ownership information. Whether or not that ownership information is actually correct, and whether or not the (in)correctness can be verified by Mozilla's software, are different issues. I can't say for certain if you are the real John Nagle, but does my uncertainty mean that I can claim that you have not told me your name? Unverified != Non-existent. IMHO, if the O= field is present but Mozilla's software cannot verify that the validation procedures that led to the issuance of the cert are good enough, then Mozilla's software should simply say nothing at all about ownership information. <snip> > As a technical note <snip> > This is a mess because the CA/Browser Forum didn't coordinate with the IETF > and X.509 when they put that info in there. Once you know the above, > though, it's not hard to implement. Sorry John, but you're pointing the finger at the wrong standards org. The Certificate Policies extension has been defined in the ISO/ITU spec (X.509) and IETF RFCs (2459, 3280 and 5280) for years. The CABForum specs aren't intended to duplicate everything contained within these other specs.
It is a mess, but the mess goes further back, and it's not the CA/Browser Forum's fault. The "X.509 Style Guide", although dated, is worth a read, as it describes the various specs, their ambiguities, and disagreements. http://www.clizio.com/S3/docum/X509StyleGuide.pdf They write: "Unfortunately on top of this there are qualifiers for the certificatePolicies and the policyConstraints extension to muddy the waters. As a result, a certificate policy often consists of a sequence of things identified by unknown object identifiers, each with another sequence of things identified by partially known, partially unknown object identifiers, with optional extra attachments containing references to other things which software is expected to know about by magic or possibly some form of quantum tunnelling."
I am not opposed to this in general. We should not change the security indicators until we have a comprehensive plan for them. The appearance in the site identify block of certificates sold by CAs in our root program is one of our biggest bargaining chips for reform. It is likely that we are better off having additional requirements on CAs and/or websites that want to have this improved UI--e.g. support for OCSP stapling, support for Google's Certificate Transparency mechanism, etc. Also, we need to understand better how users interpret the UI, and how this change interacts with other changes we may make--e.g. what triggers the green bar vs. the blue bar. I think it is *very* likely that we can find better criteria for these decisions than the presence or lack of a particular OID in the certificate.
OS: Mac OS X → All
Hardware: x86 → All
Re: "We should not change the security indicators until we have a comprehensive plan for them." I agree regarding the green bar. That should not change. I'm merely suggesting that, if location information is in the cert, and annotated with the new CA/Browser Forum OIDs, it should be displayed in the pop-up. "Does not supply ownership information" is incorrect when the cert does, in fact, supply that information.
I strongly agree that we should stop showing "This website does not supply ownership information" and "which is run by (unknown)". The simplest way to do that is to just remove both of those fields in the UI. I am not sure we need do do anything more than that right away.
(In reply to Brian Smith (:bsmith) from comment #10) > I strongly agree that we should stop showing "This website does not supply > ownership information" and "which is run by (unknown)". The simplest way to > do that is to just remove both of those fields in the UI. I am not sure we > need do do anything more than that right away. +1
(In reply to Brian Smith (:bsmith) from comment #10) > I strongly agree that we should stop showing "This website does not supply > ownership information" and "which is run by (unknown)". The simplest way to > do that is to just remove both of those fields in the UI. I am not sure we > need do do anything more than that right away. +1 if this can be done for non-EV. I think we would still want to show the run-by/owner info for EV.
(In reply to Kathleen Wilson from comment #12) <snip> > I think we would still want to show the run-by/owner info for EV. Section 6.1.1 of the EV Guidelines says... "The primary purposes of an EV Certificate are to: (1) Identify the legal entity that controls a Web site: Provide a reasonable assurance to the user of an Internet browser that the Web site the user is accessing is controlled by a specific legal entity identified in the EV Certificate..." So I agree that "run by" makes sense for EV (although I'd prefer to see "controlled by"). However... Section 10.6.1 of the EV Guidelines says... "10.6.1 Verification Requirements The CA MUST confirm that the Applicant: (A) Is the registered holder of the Domain Name, or (B) Has been granted the exclusive right to use the Domain Name by the registered holder of the Domain Name;" If (A) was the only option, then it would make sense to display "ownership information", since "owner" and "registered holder" are synonymous. But, since (B) is an option, and since an EV Certificate doesn't tell you whether the CA confirmed (A) or (B), you can _never_ be sure that an EV Certificate identifies the domain's owner. So I vote that you remove "Owner:" for all certificate types.
(In reply to Rob Stradling from comment #13) > > I think we would still want to show the run-by/owner info for EV. > > Section 6.1.1 of the EV Guidelines says... > "The primary purposes of an EV Certificate are to: > (1) Identify the legal entity that controls a Web site: Provide a reasonable > assurance to the user of an Internet browser that the Web site the user is > accessing is controlled by a specific legal entity identified in the EV > Certificate..." By "controls" I shall assume "owns a right to allocate the assets of". > Section 10.6.1 of the EV Guidelines says... > "10.6.1 Verification Requirements > The CA MUST confirm that the Applicant: > (A) Is the registered holder of the Domain Name, or > (B) Has been granted the exclusive right to use the Domain Name by the > registered holder of the Domain Name;" > > If (A) was the only option, then it would make sense to display "ownership > information", since "owner" and "registered holder" are synonymous. > > But, since (B) is an option, and since an EV Certificate doesn't tell you > whether the CA confirmed (A) or (B), you can _never_ be sure that an EV > Certificate identifies the domain's owner. > > So I vote that you remove "Owner:" for all certificate types. How would this be a problem? If the organization that has been granted the exclusive right to use a particular DNS name is the EV-validated one, the name in the green bar is the hosting company. If the organization that can grant the exclusive right to use a particular DNS name is the EV-validated one, then the name in the green bar is the domain owner's. The only thing we (the users, and quite probably the state too) need EV for is to figure out that who answers for the content of the site is who we think it is. For this purpose, eliding "Owner:" is counterproductive. Perhaps "Content by:"? That causes problems when it's an individual who owns the content, but it's hosted by an organization that can pass EV. Really, why is there no EV for individuals? That's the problem that we need to be solving, not "removing interpretive UX context from the end user simply because there's a technical inconsistency that makes no word have effective perfection". What word would you suggest to replace it?
Certificates use the terms "Subject" and "Organization". Those seem appropriate for display purposes. All Mozilla needs to do is format what's in the cert. As for EV for individuals, there is now a standard for organizationally validated certs for individuals. The OIDs for "Given name" and "Surname" may now start appearing in the occasional cert.
Would Mozilla consider displaying "meta-data" for the issuer, instead of just extracting the Issuer's name from the cert? Symantec, and I presume other CAs, might prefer in some cases to supply a more concise or descriptive string. Microsoft supports this in IE.
I filed bug 795963 to track the work in implementing the change suggested in comment 10. (In reply to Rick Andrews from comment #16) > Would Mozilla consider displaying "meta-data" for the issuer, instead of > just extracting the Issuer's name from the cert? Symantec, and I presume > other CAs, might prefer in some cases to supply a more concise or > descriptive string. Microsoft supports this in IE. Please file a new bug with more specific details of what you are requesting (what IE does).
Since posting my previous comment, I found out that for IE the friendly name is inherited down from the root cert: if the friendly name for the root is “Norton”, then all certs under that root are branded "Norton", even if Symantec wants to brand intermediates as GeoTrust, Thawte etc. This is not ideal for us, and I suspect not ideal for other CAs. So I withdraw my request. I wouldn't want Mozilla products to emulate this behavior.
Kathleen, do you object to closing this as WONTFIX? It seems this went nowhere and is not going to go anywhere. We've already filed various other bugs that can/will be acted upon as a result of this discussion.
Flags: needinfo?(kwilson)
I think the two main things coming out of this bug are: 1) Remove the following text from the popup that you get when you click on the padlock: "You are connected to mozilla.org which is run by (unknown)" 2) Remove "Owner: ..." from the Page Info popup that you get after you click on the padlock and then the "More Information" button. I cannot find an existing bug that includes these changes. So either we can change the title of this one, or make sure there are bugs created for these.
Flags: needinfo?(kwilson)
(In reply to Kathleen Wilson from comment #20) > I think the two main things coming out of this bug are: > > 1) Remove the following text from the popup that you get when you click on > the padlock: "You are connected to mozilla.org which is run by (unknown)" > > 2) Remove "Owner: ..." from the Page Info popup that you get after you click > on the padlock and then the "More Information" button. > > I cannot find an existing bug that includes these changes. So either we can > change the title of this one, or make sure there are bugs created for these. As I mentioned in comment 17, I filed bug 795963, which got duped to bug 444980, so bug 444980 is the action item from here. To save a round-trip, based on Kathleen's comment, I am going to resolve this bug now. I guess INVALID is better than WONTFIX because we don't consider the 2.23.140.1.2.2 to be a meaningful (valid) indicator in a certificate.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.