Re: Identrust Commercial Root CA 1 EV Request
On February 21 2018, I reported an unexpired certificate to Identrust which contained SAN entries for several invalid .INT domains: https://crt.sh/?id=7852280 They acknowledged and revoked the certificate in a timely manner. However, I find this event particularly bothersome: - This certificate was created for Identrust's own internal use. - The issue of .int being a valid TLD has been communicated and well-known since 2009 [1] - I don't believe Identrust has disclosed this misissuance as required. -Nick [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/L9A67IryHu0/RzeaEgIjt48J ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
On 10/15/18 11:01 AM, Kathleen Wilson wrote: I have added the following section to the Required Practices wiki page: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS I will continue to appreciate feedback on this update. Thanks, Kathleen Oops... here's the correct link: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
On 15/10/2018 20:01, Kathleen Wilson wrote: I have added the following section to the Required Practices wiki page: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CP.2FCPS_Structured_According_to_RFC_3647 links directly to the edited section. 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: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
I have added the following section to the Required Practices wiki page: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#BR_Commitment_to_Comply_statement_in_CP.2FCPS I will continue to appreciate feedback on this update. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
On 10/15/18 12:48 AM, Pedro Fuentes wrote: Hello, I've a question closely related to this. I'd appreciate guidance. I'm refactoring our CP & CPS documents considering that a CA can issue different types of certificates, so there would be multiple CP and one CPS. My strategy is that if the stipulation is defined in one of the document (CP or CPS), then the other document can refer to the other (CPS or CP). So, for example, as the CPS will support/implement different CP, for certain aspects (i.e. suspension), I'd like to refer to the CP as source, with the text "As stipulated in the appropriate CP". Like wise, in certain cases the stipulation could be defined in the CPS, so the CP would have the text "As stipulated in the CPS". This means that someone evaluating the practices for SSL certificates would have to consider jointly the CP of SSL certificates and the CPS, while someone evaluating personal certificates for email should consider the CP for S/MIME certificates and the CPS. I used this in the past while writing some docs for customers... Would this be cross-referencing still acceptable? Thanks, Pedro Yes, cross-referencing is still acceptable, as long as it is very clear which root certificates each CP and CPS document governs. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Violation report - Comodo CA certificates revocation delays
On 12/10/2018 20:01, Rob Stradling wrote: On 12/10/18 16:40, Ryan Sleevi via dev-security-policy wrote: On Fri, Oct 12, 2018 at 8:33 AM Ben Laurie wrote: This is one of the reasons we also need revocation transparency. As tempting as the buzzword is, and as much as we love motherhood and apple pie and must constantly think of the children, slapping transparency after a word doesn't actually address the needs of the community or users, nor does it resolve the challenging policy issues that arise. Just because something is cryptographically verifiable does not mean it actually resolves real world problems, or does not introduce additional ones. A simpler solution, for example, is to maintain an archive of CRLs signed by the CA. Which would address the need without the distraction, and without having the technical equivalent of Fermat's Last Theorem being invoked. Let's not let the perfect (and unspecified) be the enemy of the good and reasonable. FWIW, we (Comodo CA) do maintain an archive of all the CRLs we've ever signed. FYI, the point would be for a third party to archive copies of the CRLs, in order for the community to detect that CAs (do not) attempt to falsify their history of past revocations. It appears that crt.sh is already providing this service to the community, albeit without a cryptographic timestamp signature on the evidence that crt.sh had indeed seen specific CRLs before a certain date/time. However the mere existence of contradictory CRLs covering the same date range would already be significant evidence against any such rogue 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
undisclosed intermediate certificate
The following incident report regarding the item of undisclosed certificates has recently been posted to https://bugzilla.mozilla.org/show_bug.cgi?id=1455132 1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date. SwissSign was notified about the 5 undisclosed intermediate certificates over mozilla.dev.security.policy forum, on 2018-10-09 https://groups.google.com/d/msg/mozilla.dev.security.policy/Xb1VILzt9xk/tpW8tiE5BAAJ 2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done. Actions taken: 2018-10-09: Incident Notification by mozilla.dev.security.policy forum 2018-10-10: The 5 undisclosed certificates (see comment #7) were carefully examined by SwissSign and immediately disclosed, on 2018-10-10, the day after the notification. 2018-10-10: Juerg Eiholzer wrote an update comment (comment #9) 2018-10-15: Juerg Eiholzer provides the incident report 3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation. We didn't stop the CA issuing certificates, because we immediately solved the problem of undisclosed intermediate certificates and no misissuance of leaf certificates happened. 4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued. There is neither evidence nor indication that misissuance of leaf certificates occurred. 5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. n/a, since no real misissuance happened. 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. SwissSign's process for the retrospective correction of the disclosure for the intermediate certificates didn't work properly. This is especially due to the exchange of responsible persons within the organization. 7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things. SwissSign checked the description of the procedure of the key ceremony against the disclose requirements, stated in Mozilla Root Store Policy Version 2.6.1, section 5.3.2. The explicit task of “disclosure of CA within 7 days” is mentioned and is part of the ceremony protocol, inclusive notification to the SwissSign compliance office, which is responsible for the entry to the CCADB. Education of the responsible staff again took place. 2018-10-15 / juerg.eihol...@swisssign.com ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CCADB System Upgrades October 15, 8am-6pm Pacific Time
All, The CCADB system upgrades are in progress, so there will be limited functionality today. Best to avoid logging into CCADB today if you can. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mitigating DNS fragmentation attacks
On Mon, 15 Oct 2018 at 04:51, Paul Wouters via dev-security-policy wrote: > > On Oct 14, 2018, at 21:09, jsha--- via dev-security-policy > wrote: > > > > There’s a paper from 2013 outlining a fragmentation attack on DNS that > > allows an off-path attacker to poison certain DNS results using IP > > fragmentation[1]. I’ve been thinking about mitigation techniques and I’m > > interested in hearing what this group thinks. > > > > The mitigation is dnssec. Ensure your data is cryptographically protected. That would be nice, but as that is not available to everyone, a comprehensive solution is also desirable. -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incident Report - Misissuance of one certificate without DNS CAA authorization (Certigna)
Hello, The decision was taken at one of our security committees where all changes and developments that could impact the practices and compliance of our authority are validated. This is why all the actors of these security committees have been made aware of the incident and the fact that we can not make any exception to BR practices on the pretext that we have other additional measures implemented in our organization, in addition to all the other actions listed above. Wayne: Indeed, thank you for this return, I had corrected only chapter 4.2.1 in alignment with our CP / CPS. The file has been updated at chapter 3.2.2.8 and is available at the following address: https://bugzilla.mozilla.org/attachment.cgi?id=9017115 Best regards ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: What does "No Stipulation" mean, and when is it OK to use it in CP/CPS?
Hello, I've a question closely related to this. I'd appreciate guidance. I'm refactoring our CP & CPS documents considering that a CA can issue different types of certificates, so there would be multiple CP and one CPS. My strategy is that if the stipulation is defined in one of the document (CP or CPS), then the other document can refer to the other (CPS or CP). So, for example, as the CPS will support/implement different CP, for certain aspects (i.e. suspension), I'd like to refer to the CP as source, with the text "As stipulated in the appropriate CP". Like wise, in certain cases the stipulation could be defined in the CPS, so the CP would have the text "As stipulated in the CPS". This means that someone evaluating the practices for SSL certificates would have to consider jointly the CP of SSL certificates and the CPS, while someone evaluating personal certificates for email should consider the CP for S/MIME certificates and the CPS. I used this in the past while writing some docs for customers... Would this be cross-referencing still acceptable? Thanks, Pedro El viernes, 12 de octubre de 2018, 2:27:49 (UTC+2), Kathleen Wilson escribió: > Based on the input into this discussion so far, I propose to add the > following section to the Required part of this wiki page: > https://wiki.mozilla.org/CA/Required_or_Recommended_Practices > > We can consider adding text about this directly to Mozilla's Root Store > Policy later. (I'll file the request/issue in github.) > > -- Proposed Text -- > Section Heading: CP/CPS Structured According to RFC 3647 > > CP/CPS documents must be structured according to RFC 3647. This > requirement is stated in section 2.2 of the CA/Browser Forum Baseline > Requirements, with the effective of 31 May 2018. Further, CP/CPS > documents should include every component and subcomponent, and the > placement of information should be aligned with the BRs; e.g. domain > validation practices should be documented in section 3.2.2.4 of the CA’s > CP/CPS. > > The words "No Stipulation" mean that the particular document imposes no > requirements related to that section. > > Any CPS that falls within the scope of Mozilla’s program must not use > the words “No stipulation” unless the corresponding section in the > CA/Browser Forum Baseline Requirements state “No stipulation”, “Not > applicable”, or is blank. The words “Not applicable” are acceptable to > indicate that the CA’s policies forbid the practice that is the title of > the section. Language similar to “We do not perform section>” is preferred. If a full description of a section is repeated > elsewhere in the document, language similar to “Refer to Section 1.2.3” > is preferred. > > Examples: > - If your CA does not allow a particular domain validation method to be > used, then the CP or CPS should say that, e.g. "This method of domain > validation is not used". > - The BRs do not allow certificate suspension, so the CA’s CPS must > state that certificate suspension is not allowed, and then the other > sections related to suspension should say “Not applicable”. > - If your CA does not issue SSL certs containing IP addresses, then > section 3.2.2.5, ‘Authentication for an IP Address’ in your CP or CPS > should say that such certificate issuance is not allowed; e.g. “No IP > address certificates are issued under this CPS.” > > > I will appreciate your constructive feedback on this. > > Thanks, > Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
