Re: FNMT Root Inclusion Request
>> FNMT has applied to include the “AC RAIZ FNMT-RCM” root certificate >> and enable the Websites trust bit. >> >> Fábrica Nacional de Moneda y Timbre (FNMT) is a government agency >> that provides services to Spain as a national CA. >> >> The request is documented in the following bug: >> https://bugzilla.mozilla.org/show_bug.cgi?id=435736 Here's a summary of the audit information that has been provided, and the intermediate certs that have been revoked (to be added to OneCRL). WebTrust CA audit statement from PricewaterhouseCoopers dated May 18, 2016 https://bug435736.bmoattachments.org/attachment.cgi?id=8766584 Root certificates covered: FNMT-RCM Root CA Intermediate certificates covered: “CA Administracion Publica” and “CA Components Informaticos” WebTrust BR audit statement from PricewaterhouseCoopers dated May 18, 2016 https://bug435736.bmoattachments.org/attachment.cgi?id=8766583 Root certificates covered: FNMT-RCM Root CA Intermediate certificates covered: “CA Administracion Publica” and “CA Components Informaticos” ETSI TS 101 456 audit certificate from TUVIT dated 2016-06-21 https://bug435736.bmoattachments.org/attachment.cgi?id=8775143 Root certificates covered: OU=AC RAIZ FNMT-RCM Intermediate certificates covered: CN = AC Administracion Publica CN = AC FNMT Usarios CN = AC Representacion Audit Attestation by TUVIT https://bug435736.bmoattachments.org/attachment.cgi?id=8775145 Root certificates covered: OU=AC RAIZ FNMT-RCM “The assessment covered the period from May 6, 2015 until May 4 2016. It was verified that the CA’s “AC FNMT Usuarios” and “AC Representacion” don’t issue SSL/TSL certificates” Intermediate certificates revoked and to be added to OneCRL: https://bugzilla.mozilla.org/show_bug.cgi?id=1263949 subject: C=ES, O=FNMT-RCM, OU=AC APE sha1 hash: 8A:8E:8D:48:BC:44:F7:9D:80:67:F8:0F:14:1E:C5:A0:A9:97:99:D5 sha256 hash: FD:01:90:1F:E7:C4:F5:14:D6:36:DF:64:C0:74:4A:A4:02:9D:B9:16:A3:6F:28:47:4C:84:0E:68:07:93:6A:1E subject: C=ES, O=FNMT-RCM, OU=AC APE sha1 hash: 24:F1:1E:3F:73:DE:D8:92:D4:F0:E3:3B:8A:8F:5A:A5:21:88:A3:C2 sha256 hash: 0D:4C:32:4B:B0:B0:08:F4:5E:EC:73:8B:8E:51:B3:7D:25:0F:76:F0:5F:6A:0C:30:13:66:10:20:A2:07:25:65 subject: C=ES, O=FNMT-RCM, CN=ISA CA sha1 hash: 5E:7F:EE:F9:4C:1F:C5:C6:A2:34:46:8C:89:6B:5D:BA:CA:05:97:69 sha256 hash: 05:2B:EB:BD:CD:5C:84:7B:FA:0F:6F:B0:EA:22:46:B5:5B:A9:EE:55:E0:2A:2D:48:0B:87:FC:2F:34:2C:84:43 subject: C=ES, O=FNMT-RCM, OU=AC APE sha1 hash: 35:EC:75:F8:81:25:03:39:D1:52:5F:EB:0E:23:44:BC:DE:7A:5A:5C sha256 hash: C0:81:EA:C7:B9:80:7B:70:BD:DC:AC:13:1F:07:B6:67:E4:D9:DE:7F:56:8C:43:BA:01:11:13:A1:E7:53:48:99 subject: C=ES, O=FNMT-RCM, CN=EU ISA CA sha1 hash: 7C:C6:1C:DE:A5:7E:02:6E:2D:A5:C3:C7:66:01:39:A6:6E:AC:80:DE sha256 hash: BF:1C:7E:BA:A0:AC:08:9C:16:DD:C7:EA:03:88:D8:3F:47:21:DD:86:2F:E8:71:5E:19:BA:07:82:AE:D1:46:FE subject: C=ES, O=FNMT-RCM, CN=EU ISA CA sha1 hash: B5:CF:1B:22:8A:1A:A3:93:84:3A:C8:02:AB:F9:58:A1:A5:5F:DF:ED sha256 hash: 69:9C:E8:E2:05:65:1E:F4:8B:03:85:33:15:AE:48:2C:A0:4B:F2:B3:E2:D9:B5:A5:EF:08:E8:CB:13:86:9B:B6 The action items that had resulted from the discussion of this request are as follows. >> 1) FNMT and Mozilla will need to make sure the revoked intermediate >> certificates get added to OneCRL. >> >> 2) The "AC FNMT Usuarios" intermediate certificate will need to be >> audited annually to ensure that it never issues TLS/SSL certificates. >> If the audit ever comes back inconclusive or if there is ever any doubt >> that such an audit could detect any inadvertent issuance, the assumption >> should be that miss-issuance has occurred and it would be reasonable to >> act accordingly. >> >> 3) FNMT will work with the CAB Forum to resolve the conflicts between >> the BRs and the requirements that Spanish CAs must follow (i.e. the >> certlint errors, https://bugzilla.mozilla.org/show_bug.cgi?id=435736#c160). I believe that these action items have or are being addressed such that we may move forward with approving FNMT's request to include the “AC RAIZ FNMT-RCM” root certificate and enable the Websites trust bit. If there are no further concerns then I will close this discussion and recommend approval in the bug. (https://bugzilla.mozilla.org/show_bug.cgi?id=435736) Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Server certificate domain validation bug
Hi Nick, Sorry for the slow reply. > -Original Message- > From: Nick Lamb > Sent: 30 July 2016 00:04 > To: mozilla-dev-security-pol...@lists.mozilla.org > > Hi Robin, > > On Friday, 29 July 2016 18:54:56 UTC+1, Robin Alden wrote: > > We received a report of bugs in the construction of the emails we send out > > in order to confirm authorization by the domain name registrant prior to > > issuing a server certificate. > > > > Colloquially these are known as Domain-Control Validation Emails. > > Indeed. A few questions arise. First about this specific occurrence, all > questions are about the state prior to the incident. It's interesting to hear > about things which have changed, but my focus at first is on how things were > _before_ you knew about this specific problem. > > 1. Did Comodo grasp that these emails were a critical element of their CA > systems? e.g. do you have a document that calls them out as being important > in this way and distinguishes them from marketing communications and > other "fluff" that, though it may be important to your business, is not vital to > the web PKI ? > Hmm, that's one of those 'When did you stop beating your wife?' type questions. Yes, Comodo grasps that these emails are a critical element of the CA system. We treat the sending of these emails differently from marketing communications, although that is not hard since marketing communications come from different systems. We treat the sending of these emails differently from the sending of other emails concerning the certificate lifecycle, precisely because we are aware that they are a critical piece of the validation and issuance process. > 2. Was it impressed upon the software engineers responsible for Comodo's > software which sends these emails how critical this content was ? Were they > given suitable training e.g. based on OWASP in how to make the software > secure against well-known risks like this ? > Yes, the development team that maintains the CA software use a development process that includes review of all code by staff with experience and training in secure coding techniques. > 3. Had Comodo engaged a third party to conduct penetration testing of their > web site https://secure.comodo.com/ ? How often was this testing > done ? Yes. We are required to have this done at least annually. > If so, did that engagement include > these emails as part of the system to be tested ? These emails were generated, sent, received by, and interacted with by the pen testers as part of the pen test. Could we have drawn more attention to these emails for the pen testers as a special area of interest, and will we do so in the future? - yes. > > 4. How long had this bug been present in your production systems, and to > what certainty do you know this answer ? > Since Jan 23rd, 2015. The date is tracked as part of the change control system. > > https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard- > ssl- > > certificates-from-comodo-via-dangling-markup-injection/index.html > > Thanks for the link. > > > We are pleased to report that no certificates were issued contrary to the > > terms of our CPS. > > Two more, this time from the point of view of Comodo after the problem > was reported: > > 5. What methods were actually used to determine whether any certificates > had been issued contrary to the terms? Were those methods independent > of the specific technique used in this incident, or did they assume that this > method was the only possible means by which certificates might be mis- > issued by Comodo at this time ? > Our investigation covered the effects of markup injection into the DCV emails. We retain all details associated with a certificate request in a database. This data is not changed or deleted once a certificate is generated from the request. > 6. Given the timeline established in question 4, were you able to perform > such checks for the whole period affected, or only some of it ? > For the whole period. > > We will be further engaging with external security consultants to ensure > > that our systems remain secure so that we may continue to meet our policy > > obligations. > > Now a final question from the point of view of the incident having happened, > but independent of Comodo itself: > > 7. In your view what new requirements should be imposed on CAs by CA/B > or by the individual trust stores in order to reduce the risk of this sort of > incident in future, whether at Comodo or another CA ? I'm going to decline to suggest what anyone should impose. I would say that having more eyes on the code is always a good thing. Specifying a white-box pen test would be one way to have that effect. It may be the case that just not using the same pen tester twice in a row would provide an improvement in coverage for little or no increase in cost. Regards Robin smime.p7s Description: S/MIME cryptographic signature ___
RE: Server certificate domain validation bug
Hi Hanno, Simplicity is certainly a powerful aid to security. I like the text-only idea for the DCV emails. Not containing any user controlled content is a harder sell, I think, because we really want to give the domain owner all the information we can about the certificate request that has been submitted. We anticipate that in the Enterprise case it is of significant value to the applicant if the DCV email contains some information to assist the recipient of the DCV email to relate the certificate request to his organization's operation. A message such as this could save them a lot of time: "Required for https://svn.bambleweeny.net/trac/Project57/ticket/123, please phone Bob Kahn on extension #2719 if questions arise." Although I can see that this message looks pretty similar "Required for https://phishingsport.darknet/we_have_cookies, please phone Pete McNasty on +963-444-4 if questions arise." and expecting the recipient to tell the difference between the two approaches pre-supposes a non-knuckle-dragging domain administrator. If we pass no user controlled content at all, the problem is that in the Enterprise case the domain administrator doesn't know who (within his organization) originated the certificate request. The domain administrator needs some out-of-band communication with the applicant to be certain that the certificate request originated within his organization. I suppose the problem there is really one of the Enterprise's policy in regard to the approval of issuance of certificates for its domains being up to scratch. Regards Robin Alden Comodo smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incomplete Intermediate Cert Records
On 8/6/16 9:16 AM, Ryan Sleevi wrote: On Saturday, August 6, 2016 at 1:21:29 AM UTC-7, Kurt Roeckx wrote: I guess the same could go for e-mails about reminders that their audit period is over and should put up a new audit report, at least if they're really late. Yes, that is precisely why I mentioned it generically. I was thinking that any time a CA has to be proactively notified or reminded of its obligations, there's a public interest value. Kathleen already publishes the responses to surveys, which are very valuable to know when a CA commits to do X, but then fails, but also having the reminders public would further help inform which organizations may be having difficulty operating in a fully trustworthy manner. Sure, mistakes happen, so you wouldn't want to dig out the pitchforks the moment you saw such an email, but if the public is seeing patterns or routine negligence, it would seem appropriate to discuss further steps. I have added this to our to-do list. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intermediate certificate disclosure deadline was 2 weeks ago!! (was Re: Salesforce offline Tuesday, June 28, for data import)
On 09/08/16 00:16, Kathleen Wilson wrote: It seems to me that as long as a revoked intermediate certificate has been disclosed (i.e. in Salesforce) that the certificates that it signed do not need to be disclosed. I've just changed "Probably!" to "Unknown" (for the "Unconstrained, but all unexpired observed paths Revoked" group on https://crt.sh/mozilla-disclosures). "Unknown" is appropriate because crt.sh cannot know whether or not it has observed all of the paths that exist. -- 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: Server certificate domain validation bug
On 30/07/16 00:03, Nick Lamb wrote: >> Colloquially these are known as Domain-Control Validation Emails. > > Indeed. A few questions arise. These are good questions. I would also be interested in the answers. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
