Re: SSL Certs for Malicious Websites
[ Disclaimer: This message is my personal view and does not necessarily represent that of my employer. ] On Fri, May 20, 2016 at 5:41 PM, wrote: > Peter -- the reference to BR 9.6.8(8) is interesting, but is not really > relevant to discussion of the requirements of BR 4.2.1 through 4.9.10 quoted > by Kathleen in her first message above (and which are enforced by Section 5 > of the Baseline Requirments WebTrust audit - see > http://www.webtrust.org/homepage-documents/item76002.pdf) What about those > sections? Look again at the first analysis I posted. > > I don't understand the resistance to complying with these provisions -- it's > not that hard. > > If you think the requirements of BR 4.2.1 through 4.9.10 should be softened > or deleted, then I suggest you are the one who needs to propose a ballot! > CAs have been following these rules for about eight years now, so there is a > pretty solid history and precedence. You are right, it is not hard to comply with 4.2.1 to 4.9.10. However they say absolutely nothing about malware. The do discuss "misuse" but it is up to the CA to define misuse. From the sections you explicitly called out in your original email: 4.9.3: Requires CAs provide ability for anyone to report things. No action is required of the CA other than accepting the report. 4.9.2: Says what must be in a certificate problem report, does not address processing the report. 4.9.5: CA must decide _if_ revocation is warranted. However does not state conditions under which revocation must be warranted. 4.10.2: CA must be able to respond to problem reports 24x7. _Where_appropriate_ the CA can either forward the complaint to law enforcement and/or revoke the certificate. Again does not specify any conditions where the CA must do so. 4.9.1.1(4): Requires the CA to revoke if the Certificate was misused. CA is free to define misuse as they see fit. 4.2.1: Requires "additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements." Simply requires CAs to be sure they are properly identifying the subject authorization and DNS name control, as that is what is verified. High Risk Certificate Request: ": A Request that the CA flags for additional scrutiny by reference to internal criteria and databases maintained by the CA". Does not define any specific mandatory requirements for the criteria or database contents. It does have "may include", but that means it is up to the CA. I think one of the things that frequently is missed by people not used to technical specifications is the meaning of section 1.6.4 of the BRs. It says that the 'words “MUST”, “MUST NOT”, "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in these Requirements shall be interpreted in accordance with RFC 2119.' This basically means that anything labeled "should", "may", "recommended", or "optional" can be ignored. The BRs become much clearer if you simply remove all the text that uses these words. This is why I recommended that they be amended if there is a desire that CAs be required to do something currently allowed to be ignored. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Disclosure of intermediates that chain to multiple roots
On Friday, May 20, 2016 at 2:39:20 AM UTC-7, Rob Stradling wrote: > On 19/05/16 21:48, Kathleen Wilson wrote: > > On Monday, May 16, 2016 at 1:33:40 PM UTC-7, Rob Stradling wrote: > >> However, ISTM that a "proposed change currently in discussion" is less > >> authoritative than the CA Communication (which, as I've said, seems to > >> explicitly require multiple disclosures of the same intermediate when > >> multiple trust paths exist). > >> > >> Assuming everyone's happy with my suggested resolution, please would you > >> update the requirements for "ACTION #2" before the end of June (the > >> earlier the better!) so that multiple disclosures are not required? > > > > > > It's too late to update the CA Communication itself, so I will provide the > > update here. > > > > > > Proposed by Rob: > >1. Require https://crt.sh/?id=1790 to be disclosed precisely once, by > > Web.com, because the chain up to Web.com's Built-in Root is the shortest > > chain. > >2. Hold both Web.com and Comodo equally to blame if > > https://crt.sh/?id=1790 is not disclosed. (The gives Comodo the > > incentive to ensure that Web.com do disclose it). > > > > I agree with this proposal, but will try to clarify a bit more... > > For root certificate A that is cross-signed by another included root > > certificate B (that has the Websites trust bit enabled), the intermediate > > certificates chaining up to A only need to be disclosed once. > > The cross-certificates for root certificate A must be entered into > > Salesforce, chaining to root certificate B. > > If root certificate A is included and has the Websites trust bit enabled, > > then its intermediate certificates should be entered into Salesforce such > > that they chain directly to root certificate A. > > If root certificate A has been removed from NSS or does not have the > > Websites trust bit enabled, then its intermediate certificates must be > > entered into Salesforce such that they chain to root certificate B. > > Great. That's completely clear. Thanks Kathleen. > I added text about this to the wiki page: https://wiki.mozilla.org/CA:SalesforceCommunity#Which_intermediate_certificate_data_should_CAs_add_to_Salesforce.3F Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL Certs for Malicious Websites
On Friday, May 20, 2016 at 5:29:43 PM UTC-7, Peter Bowen wrote: > [ Disclaimer: This message is my personal view and does not > necessarily represent that of my employer. ] > > On Fri, May 20, 2016 at 3:19 PM, wrote: > > On Friday, May 20, 2016 at 12:22:07 PM UTC-7, Peter Bowen wrote: > >> > >> When it comes to public certificates, which is what the Mozilla CA > >> program covers and are the subject of the BRs and EV Guidelines > >> (EVGs), there is assurance that certificates do the the following: > >> > >> Provide global identification by certifying: > >> 1) A binding between the identity of a natural person or institution > >> and a cryptographic key > >> 2) Confirmation that the identified named entity authorized issuance > >> of the certificate > >> Alternatively they explicitly may not provide identity. > >> > >> Provide assurance that the subscriber either had control of the hosts, > >> control of the domain namespace, or was a contact for the domain > >> namespace for all DNS names or the equivalent for all alternative > >> names in the certificate at the time the certificate was issued. In > >> some cases, such as an electronic identity certificate, there may be > >> no alternative name. > >> > >> This is all that they do. Now some CAs may choose to make further > >> assurances, for example they may assert that the person named in the > >> certificate is a citizen of a certain country or assert that the > >> company is a member of an organization or has been licensed for > >> certain activities However this is outside the scope of the BRs and > >> EVGs. > > > > Now you have really stumped me, Peter. Are you saying the BR provisions of > > 4.2.1 through 4.9.10 quoted by Kathleen in her first message above are > > optional? I don't think that's correct. > > > > I was not proposing that CAs go beyond what is spelled out in the BRs as to > > revocation (and blocking new cert issuance), although they can if they want > > to. I was only responding to Kathleen's questions about what the quoted BR > > provisions mean -- and to me, they are mandatory, not optional. I know we > > and other CAs have been following these rules for some years. > > The only places where the BRs uses the word "malware" are: > Section 5, about protecting the CA's own system from malware and > 9.6.3 (8) which says CA must confirm that the Subscriber has > acknowledged the CA is "entitled" to revoke a certificate immediately > if the Certificate is used to enable the distribution of malware. > > If you compare this to the recent Microsoft program requirement, you > will see there is no requirement that a CA do so, rather the > subscriber has simply acknowledged they are entitled to do so. > > Kathleen has pointed out that terms like "misuse" is undefined and > suggested that the CA/Browser Forum update the BRs to define this > term. If you feel strongly that publicly trusted certificates should > certify more than identity, I would suggest you propose a ballot to > update the BRs state such. > > Thanks, > Peter Peter -- the reference to BR 9.6.8(8) is interesting, but is not really relevant to discussion of the requirements of BR 4.2.1 through 4.9.10 quoted by Kathleen in her first message above (and which are enforced by Section 5 of the Baseline Requirments WebTrust audit - see http://www.webtrust.org/homepage-documents/item76002.pdf) What about those sections? Look again at the first analysis I posted. I don't understand the resistance to complying with these provisions -- it's not that hard. If you think the requirements of BR 4.2.1 through 4.9.10 should be softened or deleted, then I suggest you are the one who needs to propose a ballot! CAs have been following these rules for about eight years now, so there is a pretty solid history and precedence. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL Certs for Malicious Websites
[ Disclaimer: This message is my personal view and does not necessarily represent that of my employer. ] On Fri, May 20, 2016 at 3:19 PM, wrote: > On Friday, May 20, 2016 at 12:22:07 PM UTC-7, Peter Bowen wrote: >> >> When it comes to public certificates, which is what the Mozilla CA >> program covers and are the subject of the BRs and EV Guidelines >> (EVGs), there is assurance that certificates do the the following: >> >> Provide global identification by certifying: >> 1) A binding between the identity of a natural person or institution >> and a cryptographic key >> 2) Confirmation that the identified named entity authorized issuance >> of the certificate >> Alternatively they explicitly may not provide identity. >> >> Provide assurance that the subscriber either had control of the hosts, >> control of the domain namespace, or was a contact for the domain >> namespace for all DNS names or the equivalent for all alternative >> names in the certificate at the time the certificate was issued. In >> some cases, such as an electronic identity certificate, there may be >> no alternative name. >> >> This is all that they do. Now some CAs may choose to make further >> assurances, for example they may assert that the person named in the >> certificate is a citizen of a certain country or assert that the >> company is a member of an organization or has been licensed for >> certain activities However this is outside the scope of the BRs and >> EVGs. > > Now you have really stumped me, Peter. Are you saying the BR provisions of > 4.2.1 through 4.9.10 quoted by Kathleen in her first message above are > optional? I don't think that's correct. > > I was not proposing that CAs go beyond what is spelled out in the BRs as to > revocation (and blocking new cert issuance), although they can if they want > to. I was only responding to Kathleen's questions about what the quoted BR > provisions mean -- and to me, they are mandatory, not optional. I know we > and other CAs have been following these rules for some years. The only places where the BRs uses the word "malware" are: Section 5, about protecting the CA's own system from malware and 9.6.3 (8) which says CA must confirm that the Subscriber has acknowledged the CA is "entitled" to revoke a certificate immediately if the Certificate is used to enable the distribution of malware. If you compare this to the recent Microsoft program requirement, you will see there is no requirement that a CA do so, rather the subscriber has simply acknowledged they are entitled to do so. Kathleen has pointed out that terms like "misuse" is undefined and suggested that the CA/Browser Forum update the BRs to define this term. If you feel strongly that publicly trusted certificates should certify more than identity, I would suggest you propose a ballot to update the BRs state such. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL Certs for Malicious Websites
On Friday, May 20, 2016 at 12:22:07 PM UTC-7, Peter Bowen wrote: > [ Disclaimer: This message is my personal view and does not > necessarily represent that of my employer. ] > > On Thu, May 19, 2016 at 9:15 AM, [Kirk Hall] wrote: > > This has been a very surprising discussion to me. If most CAs were asked > > “Do you think CAs are supposed to investigate and revoke one of your > > certificates that is reported to you for injecting malware on Relying > > Parties clients?” their answer would be “Yes, of course – that’s required > > under the Baseline Requirements (BRs) and related WebTrust audit > > requirements.” > > Kirk, > > Addressing your question directly, the _Trust Service Principles and > Criteria for Certification Authorities, Version 2.0_ (better know as > WebTrust for Certification Authorities 2.0) very much does not require > such. This WebTrust audit is designed to provide assurance that the > CA does what it says it does when it comes to Subscriber Registration > and Certificate Issuance. It is up to the CA to determine the rules > about when it issues a certificate and document those in its CPS. > > When it comes to public certificates, which is what the Mozilla CA > program covers and are the subject of the BRs and EV Guidelines > (EVGs), there is assurance that certificates do the the following: > > Provide global identification by certifying: > 1) A binding between the identity of a natural person or institution > and a cryptographic key > 2) Confirmation that the identified named entity authorized issuance > of the certificate > Alternatively they explicitly may not provide identity. > > Provide assurance that the subscriber either had control of the hosts, > control of the domain namespace, or was a contact for the domain > namespace for all DNS names or the equivalent for all alternative > names in the certificate at the time the certificate was issued. In > some cases, such as an electronic identity certificate, there may be > no alternative name. > > This is all that they do. Now some CAs may choose to make further > assurances, for example they may assert that the person named in the > certificate is a citizen of a certain country or assert that the > company is a member of an organization or has been licensed for > certain activities However this is outside the scope of the BRs and > EVGs. > > Just like state, province, territory, or district issued identity > cards in the US and Canada, Certificates do not directly assert > anything about the character of the individual identified. Someone > with multiple felony convictions can get an identity card. However, > what the identity card or certificate does so it help provide a > consistent identity that can be looked up in systems to find out about > the character of the person. > > Certificates for a critical part of securing communication. They > solve the a priori knowledge problem when initiating a conversation > with a previously unknown party. The certificate allows the one party > to say to the other "I'm Bob and you can be assured of that because > our mutual friend Charlie confirmed a much".This avoids a > switcheroo taking place where someone else claims to be Bob. > > If CAs want to add additional assertions to certificates, that should > be their prerogative. If this is included in a manner that allows > automatic extraction, then it is something that firewall or end point > security vendors might be able use to help classify websites. For > example, a certificate can declare it is a website operated by a > national government which might cause the security software to make > certain decisions. However this is out of scope for the BRs, EVGs, > and Mozilla CA program. > > Thanks, > Peter Now you have really stumped me, Peter. Are you saying the BR provisions of 4.2.1 through 4.9.10 quoted by Kathleen in her first message above are optional? I don't think that's correct. I was not proposing that CAs go beyond what is spelled out in the BRs as to revocation (and blocking new cert issuance), although they can if they want to. I was only responding to Kathleen's questions about what the quoted BR provisions mean -- and to me, they are mandatory, not optional. I know we and other CAs have been following these rules for some years. Also, you are only looking at basic WebTrust for CAs (with its new name). Take a look at BR WebTrust Sec. 5. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Japan GPKI Root Renewal Request
Does anyone have questions, concerns, or feedback on this request from the Government of Japan, Ministry of Internal Affairs and Communications, to include the GPKI 'ApplicationCA2 Root' certificate and enable the Websites trust bit? Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL Certs for Malicious Websites
[ Disclaimer: This message is my personal view and does not necessarily represent that of my employer. ] On Thu, May 19, 2016 at 9:15 AM, wrote: > This has been a very surprising discussion to me. If most CAs were asked “Do > you think CAs are supposed to investigate and revoke one of your certificates > that is reported to you for injecting malware on Relying Parties clients?” > their answer would be “Yes, of course – that’s required under the Baseline > Requirements (BRs) and related WebTrust audit requirements.” Kirk, Addressing your question directly, the _Trust Service Principles and Criteria for Certification Authorities, Version 2.0_ (better know as WebTrust for Certification Authorities 2.0) very much does not require such. This WebTrust audit is designed to provide assurance that the CA does what it says it does when it comes to Subscriber Registration and Certificate Issuance. It is up to the CA to determine the rules about when it issues a certificate and document those in its CPS. When it comes to public certificates, which is what the Mozilla CA program covers and are the subject of the BRs and EV Guidelines (EVGs), there is assurance that certificates do the the following: Provide global identification by certifying: 1) A binding between the identity of a natural person or institution and a cryptographic key 2) Confirmation that the identified named entity authorized issuance of the certificate Alternatively they explicitly may not provide identity. Provide assurance that the subscriber either had control of the hosts, control of the domain namespace, or was a contact for the domain namespace for all DNS names or the equivalent for all alternative names in the certificate at the time the certificate was issued. In some cases, such as an electronic identity certificate, there may be no alternative name. This is all that they do. Now some CAs may choose to make further assurances, for example they may assert that the person named in the certificate is a citizen of a certain country or assert that the company is a member of an organization or has been licensed for certain activities However this is outside the scope of the BRs and EVGs. Just like state, province, territory, or district issued identity cards in the US and Canada, Certificates do not directly assert anything about the character of the individual identified. Someone with multiple felony convictions can get an identity card. However, what the identity card or certificate does so it help provide a consistent identity that can be looked up in systems to find out about the character of the person. Certificates for a critical part of securing communication. They solve the a priori knowledge problem when initiating a conversation with a previously unknown party. The certificate allows the one party to say to the other "I'm Bob and you can be assured of that because our mutual friend Charlie confirmed a much".This avoids a switcheroo taking place where someone else claims to be Bob. If CAs want to add additional assertions to certificates, that should be their prerogative. If this is included in a manner that allows automatic extraction, then it is something that firewall or end point security vendors might be able use to help classify websites. For example, a certificate can declare it is a website operated by a national government which might cause the security software to make certain decisions. However this is out of scope for the BRs, EVGs, and Mozilla CA program. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL Certs for Malicious Websites
On Thu, 19 May 2016 16:52:26 -0700 (PDT) tech29...@gmail.com wrote: > Your main concern – unjustified delay in issuing a certificate to > your customer while a human looks at the domain to decide if there is > a problem - is not really related to any of Kathleen’s questions. > Your other comments express what you think the role of a CA *should* > be, but don’t address what the current BRs actually require CAs to do > (which is what Kathleen was asking). In fact, Kathleen asked explicitly for what the answers "should be" in addition to what they are, so my email was not unrelated. To be more explicit, I think the answers to questions 3-5 should be no. The reason why is explained in my email: requiring CAs to be responsible for content has unintended negative effects on HTTPS adoption. I think that causes more harm than good to Internet security. Regards, Andrew ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL Certs for Malicious Websites
On 19/05/16 00:45, Matt Palmer wrote: > How so? It could be a site providing information from a third party on how > to make and receive payments via PayPal. It could also be a site operated > by a third party on behalf of PayPal. Inferring nefarious intent from a > domain name seems like a really great way to make some fairly spectacular > mistakes. Consider my comment withdrawn :-) Don't know what I was thinking. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL Certs for Malicious Websites
On 18/05/16 17:35, Ben Wilson wrote: > Looking at the threat from a defense-in-depth/orthogonal perspective, > doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does > something to combat malicious websites for the public? Not necessarily, if what they do ends up damaging innocent parties due to lack of sufficient information. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Request to enable EV for VeriSign Class 3 G4 ECC root
On 19/05/16 20:26, Peter Kurrasch wrote: > My recommendation is for Mozilla to reject this request from Symantec > on the grounds that it is unnecessary. As others have pointed out > recently, the chief function of a CA is to certify identity. That > certification should be ably met with the regular cert issuance > procedures rendering the EV procedures superfluous. You have this the wrong way around. Mozilla's position (de facto, I guess) is that anything short of EV is not sufficient validation of identity. Which is why we don't present it in the UI. So yes, an important function of a CA is to certify identity, and that's precisely why we have EV. > That, or perhaps > the CA knows of certain weaknesses in the regular identification > process that have been remedied for the EV process? Perhaps EV is a > way of saying, "No, seriously you guys, this time we really, really > identified the cert applicant." You would need to ask individual CAs about the way that they market and validate their non-EV certificates which purport to contain identity information. (They usually call this "OV".) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL Certs for Malicious Websites
On Friday, May 20, 2016 at 2:09:42 AM UTC-7, Ben Laurie wrote: > > 4.9.3. Procedure for Revocation Request > > > >"*** The CA SHALL provide Subscribers, Relying Parties, Application > > Software Suppliers, and other third parties with clear instructions for > > reporting suspected Private Key Compromise, Certificate misuse, or other > > types of fraud, compromise, misuse, inappropriate conduct, or any other > > matter related to Certificates. The CA SHALL publicly disclose the > > instructions through a readily accessible online means." > > I've tried a few times to find these readily accessible instructions > for any CA whatsoever. Do they exist? Where are Trend Micro's, for > example? http://www.trendmicro.com/us/enterprise/cloud-solutions/deep-security/ssl-certificates/#support PROBLEM REPORTING If you need to revoke a certificate issued by Trend Micro SSL or if you want to report a problem with a site secured by a Trend Micro SSL certificate, please send details about the problem to ssl_supp...@trendmicro.com. By the way, I no longer work for Trend Micro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Disclosure of intermediates that chain to multiple roots
On 19/05/16 21:48, Kathleen Wilson wrote: On Monday, May 16, 2016 at 1:33:40 PM UTC-7, Rob Stradling wrote: However, ISTM that a "proposed change currently in discussion" is less authoritative than the CA Communication (which, as I've said, seems to explicitly require multiple disclosures of the same intermediate when multiple trust paths exist). Assuming everyone's happy with my suggested resolution, please would you update the requirements for "ACTION #2" before the end of June (the earlier the better!) so that multiple disclosures are not required? It's too late to update the CA Communication itself, so I will provide the update here. Proposed by Rob: 1. Require https://crt.sh/?id=1790 to be disclosed precisely once, by Web.com, because the chain up to Web.com's Built-in Root is the shortest chain. 2. Hold both Web.com and Comodo equally to blame if https://crt.sh/?id=1790 is not disclosed. (The gives Comodo the incentive to ensure that Web.com do disclose it). I agree with this proposal, but will try to clarify a bit more... For root certificate A that is cross-signed by another included root certificate B (that has the Websites trust bit enabled), the intermediate certificates chaining up to A only need to be disclosed once. The cross-certificates for root certificate A must be entered into Salesforce, chaining to root certificate B. If root certificate A is included and has the Websites trust bit enabled, then its intermediate certificates should be entered into Salesforce such that they chain directly to root certificate A. If root certificate A has been removed from NSS or does not have the Websites trust bit enabled, then its intermediate certificates must be entered into Salesforce such that they chain to root certificate B. Great. That's completely clear. Thanks Kathleen. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SSL Certs for Malicious Websites
On 20/05/16 10:09, Ben Laurie wrote: On 19 May 2016 at 17:15, wrote: 4.9.3. Procedure for Revocation Request "*** The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means." I've tried a few times to find these readily accessible instructions for any CA whatsoever. Do they exist? Where are Trend Micro's, for example? Kathleen, "The CA SHALL publicly disclose the instructions through a readily accessible online means" immediately makes me think of the Mozilla CA Community in Salesforce. Is there a field in the Salesforce system (per CA Owner, I'd have thought) that indicates where the CA publishes these "clear instructions"? Also, is it your intent to make the Salesforce system publicly readable? (IINM, it's only readable by representatives of CAs at the moment). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
