RE: Possible future re-application from WoSign (now WoTrus)
Hi Peter, I am working for WoTrus as a Compliance Coordinator in the Risk Control & Compliance Department and I am the representative of WoTrus for communication in the community. Best regards, Danny -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+pa4=wotrus@lists.mozilla.org] On Behalf Of Peter Kurrasch via dev-security-policy Sent: Tuesday, November 28, 2017 11:50 PM To: Danny 吴熠; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Possible future re-application from WoSign (now WoTrus) Danny, can you please clarify your role? Are you a WoTrus employee and are you speaking on behalf of Richard Wang? Thanks. Original Message From: Danny 吴熠 via dev-security-policy Sent: Monday, November 27, 2017 2:39 AM Dear Gerv, Kethleen, other community friends, First, thanks for Gerv and Kathleen’s so kind consideration and so great arrangement for this pre-discussion. Second, thanks for the community participants to help us know our problem clearly in the past year, we wish you can give us a chance to serve the Internet security. Here is our response covered your questions that we don’t reply the emails one by one. ...snip... Finally, as a CA, we fully understand that the mistakes we have made are significant. By the sanction, we learned the importance of maintaining trust and compliance, and we hope to provide excellent products and services as compensation for our mistakes, and to serve the Internet security to regain public trust. We’d love to hear your feedback and we are trying to do better and better, thanks. Best Regards, WoTrus CA Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Swiss Government root inclusion request
On Thursday, November 23, 2017 at 4:03:27 AM UTC-7, michael.vonn...@bit.admin.ch wrote: > Hi Matt > > Thank you for your statement. > > Let me try to clarify: > > In 3.2.2.4 we specify the Authorization by Domain Name Registrant as follows: > > 3.2.2.4 Authorization by Domain Name Registrant For each Fully-Qualified > Domain Name listed in a Certificate, SG PKI confirms that, as of the date the > Certificate was issued, the Applicant (or the Applicant's Parent Company, > Subsidiary Company or Affiliate, collectively referred to as "Applicant" for > the purpose of this Section) either is the Domain Name Registrant or has > control over the FQDN by: > - communicating directly with the Domain Name Registrant using the contact > information listed in the WHOIS records "registrant", "technical" or > "administrative" field. > - Relying upon a Domain Authorization Document approved by the Domain Name > Registrant. The document MUST be dated on or after the certificate request > date or used by SG PKI to verify a previously issued certificate and that the > Domain Name's WHOIS record has not been modified since the previous > certificate issuance. > The Mozilla policy requires the CPS to reference the specific BR section, so at the very least the CPS is out of compliance because it does not contain these references. > > And in paragraph 4.2 the certificate application process is described and > refers in the end to the before mentioned checklist: > > [...] > The validation process is detailed in a checklist for each certificate type. > [25][26][27] [...] > Mozilla's Required Practices document [1] specifies more details on the amount of disclosure required for a CA's domain validation methods. > > As the checklist potentially needs to be adapted to actual threats, we chose > to leave it in a separate document and refer to it in the CPS to make the > check procedure transparent. > If required, we will adapt this procedure and integrate all steps into the > CPS. That would make the checklist document handling less agile. I would > appreciate some more input on this point from others, before we change that. > I'm familiar with a number of CPS documents and they all include details on domain validation practices. I'm also concerned about the separate document because: 1. It was not accessible when I originally requested it (404) 2. It contains a comment that implies the use of 7 methods instead of just two as stated in the CPS 3. That comment references outdated methods including "any other" 4. It appears that the document hasn't been updated in over a year and it contains no version control information other than a date and "version 1.0" > > Regards > Michael [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla RSA-PSS policy
On Tue, Nov 28, 2017 at 8:04 AM, Hubert Kario wrote: > On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote: > > On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario wrote: > > > > So no, we should not assume well-meaning actors, and we should be > > > > > > explicit > > > > > > > about what the "intention" of the RFCs is, and whether they actually > > > > achieve that. > > > > > > but we should achieve that by saying "do this", not "don't do this", > > > enumerating badness doesn't work - ask firewall people if you don't > > > believe > > > me. > > > > > > Or did we add to policy that keys revoked because they may haven been > > > compromised (heartbleed) can't be reused? Ever? Even by a different CA? > > > > You've completely misframed my proposal. I'm enumerating a specific > > whitelist of what is permitted. Every other option, unless otherwise > > permitted, is restricted. I'm even going to the level of proposing a > > byte-for-byte comparison function such that there's not even a prosaic > > whitelist - it's such that the policy is black and white and transcends > > language barriers by expressing directly in the technology. > > > > You're enumerating a blacklist - saying that all of the flexibility of > 4055 > > is permitted (except for these specific combinations), but propose to > > enforce neither of those through code or policy. > > where did I do that? > > it's the second time you're putting words in my mouth, I really do not > appreciate that. Hubert, while it's certainly not my intent to misrepresent your position, I think it's worth remarking that in your reply immediately prior, you highlighted that "but we should achieve that by saying 'Do this', not "don't do this", enumerating badness doesn't work". This was similarly putting words in my mouth - but, as I highlighted, it was a misunderstanding, and tried to clarify. To your question, the following statements were made earlier in the thread: "" - issuing certificates may include RSA-PSS parameters in the Public Key Info Algorithm Identifier, it's recommended that the hash selected matches the security of the key - signature hash and the hash used for mask generation must be the same both in public key parameters in certificate and in signature parameters - the salt length must equal at least 32 for SHA-256, 48 for SHA-384 and 64 bytes for SHA-512"" And yet, in a follow-up, you replied ""that would require hardcoding salt lengths, given their meaning in subjectPublicKeyInfo, I wouldn't be too happy about it looking at OpenSSL behaviour, it would likely render all past signatures invalid and making signatures with already released software unnecessarily complex (OpenSSL defaults to as large salt as possible)" I hope you can see how these two are in conflict - on the one hand, you suggest the policy should require X, but then suggest the implementation should not enforce X, because it would invalidate OpenSSL signatures. Similarly, with respect to the differences in our approaches, the framing you put forward is: ""for X.509 only DER is allowed, if the tags or values are not encoded with minimal number of bytes necessary, or with indeterminate length, it's not DER it's BER and that's strictly forbidden"" However, despite it being forbidden, the code contributed to NSS (and mentioned in your original post - https://bugzilla.mozilla.org/show_bug.cgi?id=1400844) does not actually enforce this. The fact that this new NSS implementation does not properly validate the well-formedness of these signatures is somewhat in conflict with your statement: ""it turned out to be a problem because a). it was the 90's, b). everybody did it like that, c). everybody assumed (not test) that security software was written, well, securely...""" So are we to conclude that this is still a problem because everybody assumes, but does not test, that NSS is written, well, securely? This is similarly an example of a policy 'requiring' X, but this is not required through code or, with your proposed policy, required through policy. When I offered suggestions of how to avoid this, you seemingly rejected them (when taking the message as a whole), with your suggestion being: ""or provide examples of specific encodings with explanations what can change and to what degree..."" Which is to afford the flexibility of 4055 by encoding a variety of parameters - yet still in seeming direct conflict with the policy proposal you yourself made. These examples of internal inconsistencies are instead why I tried to focus on first principles, and would like to revisit them. Framed differently: 1) Do you believe it represents a security risk to mix RSA-PKCS#1v1.5 and RSA-PSS signatures with the same key? 2) Do you believe it represents a security risk to mix hash algorithms within RSA-PSS signatures with the same key? These questions are, perhaps, the crux of our disagreement. They should be answered 'yes/no'. If they're yes, we should take specific steps to ensure that
Re: Possible future re-application from WoSign (now WoTrus)
Danny, can you please clarify your role? Are you a WoTrus employee and are you speaking on behalf of Richard Wang? Thanks. Original Message From: Danny 吴熠 via dev-security-policy Sent: Monday, November 27, 2017 2:39 AM Dear Gerv, Kethleen, other community friends, First, thanks for Gerv and Kathleen’s so kind consideration and so great arrangement for this pre-discussion. Second, thanks for the community participants to help us know our problem clearly in the past year, we wish you can give us a chance to serve the Internet security. Here is our response covered your questions that we don’t reply the emails one by one. ...snip... Finally, as a CA, we fully understand that the mistakes we have made are significant. By the sanction, we learned the importance of maintaining trust and compliance, and we hope to provide excellent products and services as compensation for our mistakes, and to serve the Internet security to regain public trust. We’d love to hear your feedback and we are trying to do better and better, thanks. Best Regards, WoTrus CA Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names
On 28/11/2017 15:53, Nick Lamb wrote: On Tue, 28 Nov 2017 04:26:30 +0100 Jakob Bohm via dev-security-policy wrote: Nick Lamb, in the message I replied to, clearly suggested as much, and provided a contrived scenario to "prove" that point. That's true, and I apologise if the effect was to de-rail the thread, but I certainly don't concede that just because the scenario was contrived it won't happen. I think like spear phishing we can expect to see sophisticated criminals targeting organisations through this sort of vulnerability, so-to-say "casing the joint" before their attack, figuring out exactly which services exist, what infrastructure is shared or public, looking for weaknesses. A CA needn't make that job easier. Your scenario required a number of specific actions and vulnerabilities at the victim end of things, most notably ordering a wildcard certificate and (unusually) not wanting it to cover the case of no label at the wildcard point, but also relying on the absence (after seeing its presence) of that SAN in setting up the handling of URLs for that service on the second server, and that server being vulnerable. One could certainly argue that a CA should allow the subscriber to explicitly deselect the default bonus SANs if a subscriber really wants a certificate without that SAN. But including certain traditional related SAN values at no extra charge and by default is generally a good thing. I am referring to the cost to the certificate subscriber, specifically the cost of paying for two properly validated certificates rather than two. Nick Lamb's scenario involved someone deliberately ordering both *.example.com and www.example.com as separate certificates, along with other circumstances. The price paid by the subscriber to a traditional commercial CA has essentially nothing to do with the marginal cost of issuing more certificates. If it did Let's Encrypt would have bankrupted its sponsor companies months ago. The price paid by the subscriber to a commercial CA /is/ the marginal cost as far as the subscriber is concerned. Thus it motivates subscribers to purchase fewer certificates if possible. And that's what I was referring to, not the cost to the CA or how that cost might motivate the CA. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Welcome Wayne Thayer to Mozilla!
that is great On Tue, Nov 28, 2017 at 2:03 AM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > That is great! > > On Monday, November 27, 2017 at 4:04:09 PM UTC-8, Kathleen Wilson wrote: > > All, > > > > I am pleased to announce that Wayne Thayer is now a Mozilla employee, > > and will be working with me on our CA Program! > > > > Many of you know Wayne from his involvement in this discussion forum and > > in the CA/Browser Forum, as a representative for the Go Daddy CA. Wayne > > was involved in Go Daddy's CA program from the beginning, so he has a > > deep understanding of CA policies, audits, and standards. > > > > Some of the things Wayne will be working on in his new role include: > > + Review of root inclusion/update requests in discussion. > > + Investigate more complex root inclusion/update requests. > > + Help with CA mis-issuance investigations, bugs, and discussions. > > + Lead prioritization, effort, and discussions to update Mozilla Root > > Store Policy and CCADB Policy. (transition from Gerv over time) > > + Represent Mozilla in the CA/Browser Forum, along with Gerv. > > > > I have added Wayne to the Policy_Participants wiki page: > > https://wiki.mozilla.org/CA/Policy_Participants > > > > Welcome, Wayne! > > > > Thanks, > > Kathleen > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question on CAA processing for mixed wildcard and non-wildcard SAN DNS names
On Tue, 28 Nov 2017 04:26:30 +0100 Jakob Bohm via dev-security-policy wrote: > Nick Lamb, in the message I replied to, clearly suggested as much, and > provided a contrived scenario to "prove" that point. That's true, and I apologise if the effect was to de-rail the thread, but I certainly don't concede that just because the scenario was contrived it won't happen. I think like spear phishing we can expect to see sophisticated criminals targeting organisations through this sort of vulnerability, so-to-say "casing the joint" before their attack, figuring out exactly which services exist, what infrastructure is shared or public, looking for weaknesses. A CA needn't make that job easier. > I am referring to the cost to the certificate subscriber, specifically > the cost of paying for two properly validated certificates rather than > two. Nick Lamb's scenario involved someone deliberately ordering both > *.example.com and www.example.com as separate certificates, along with > other circumstances. The price paid by the subscriber to a traditional commercial CA has essentially nothing to do with the marginal cost of issuing more certificates. If it did Let's Encrypt would have bankrupted its sponsor companies months ago. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible future re-application from WoSign (now WoTrus)
On Mon, Nov 27, 2017 at 3:07 PM, adisor19--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > After seeing the forced shutdown of StartCom, I see no reason to allow > them back in. Richard Wang is back in his role as CEO and everything is > back to square one except all trust is gone now. They killed a good > brand/company (StartCom) and did more harm to the public CA ecosystem than > Symantec's shenanigans. > > Allowing them back in is insulting IMO. > > I also lament the passing of StartCom. I liked it before the acquisition. I was a paying customer. It brings an interesting point though. If I were assessing his fitness to run a CA at this point, I would probably fault Eddy Nigg quite harshly, too. While he clearly wasn't responsible for the improper actions undertaken by Mr. Wang, he shirked a responsibility to the community in not announcing that he was no longer supervising and controlling StartCom, delaying the discovery and remediation. To the extent that he made any kind of NDA or other agreement with WoSign as part of the sale, that's still a choice he made to sign on to and such choices have consequences -- especially when it comes to trust. Matt Hardeman ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla RSA-PSS policy
On Monday, 27 November 2017 23:37:59 CET Ryan Sleevi wrote: > On Mon, Nov 27, 2017 at 4:51 PM, Hubert Kario wrote: > > > So no, we should not assume well-meaning actors, and we should be > > > > explicit > > > > > about what the "intention" of the RFCs is, and whether they actually > > > achieve that. > > > > but we should achieve that by saying "do this", not "don't do this", > > enumerating badness doesn't work - ask firewall people if you don't > > believe > > me. > > > > Or did we add to policy that keys revoked because they may haven been > > compromised (heartbleed) can't be reused? Ever? Even by a different CA? > > You've completely misframed my proposal. I'm enumerating a specific > whitelist of what is permitted. Every other option, unless otherwise > permitted, is restricted. I'm even going to the level of proposing a > byte-for-byte comparison function such that there's not even a prosaic > whitelist - it's such that the policy is black and white and transcends > language barriers by expressing directly in the technology. > > You're enumerating a blacklist - saying that all of the flexibility of 4055 > is permitted (except for these specific combinations), but propose to > enforce neither of those through code or policy. where did I do that? it's the second time you're putting words in my mouth, I really do not appreciate that. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Firefox Mobile - Which Trust Store?
On 27/11/17 19:50, Myers, Kenneth (10421) wrote: > Does Firefox mobile use the NSS trust store? Yes, on Android. It uses the OS trust store on iOS. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible future re-application from WoSign (now WoTrus)
On Wednesday, November 22, 2017 at 4:06:26 AM UTC-5, Gervase Markham wrote: > We understand that WoTrus (WoSign changed their name some months ago) > are working towards a re-application to join the Mozilla Root Program. > Richard Wang recently asked us to approve a particular auditor as being > suitable to audit their operations. > > In the WoSign Action Items bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1311824 > Kathleen wrote "WoSign may apply for inclusion of new (replacement) root > certificates[1] following Mozilla's normal root inclusion/change > process[2] (minus waiting in the queue for the discussion), after they > have completed all of the following action items, and no earlier than > June 1, 2017." > > However, one step in the inclusion process is the public discussion, and > we have some reason to believe that this may lead to significant > objections being raised. It would not be reasonable to encourage WoSign > to complete all the other steps in the process if there was little or no > chance of them being approved in public discussion. > > So Kathleen and I thought it would be best to have a pre-discussion now, > in order to make sure that expectations are set appropriately. If WoTrus > had completed all the action items in the bug and arrived at the public > discussion part of the application, what would people say? If you raise > an objection, please say if there is any way at all that you think > WoTrus could address your issue. > > Thanks for your input, > > Gerv After seeing the forced shutdown of StartCom, I see no reason to allow them back in. Richard Wang is back in his role as CEO and everything is back to square one except all trust is gone now. They killed a good brand/company (StartCom) and did more harm to the public CA ecosystem than Symantec's shenanigans. Allowing them back in is insulting IMO. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
