Re: Misissuance/non-compliance remediation timelines
So your view is the “carrot” is getting to use Mozilla’s brand as an endorsement, and the “stick” being that if you don’t get that endorsement for a while, you get kicked out? The assumption is that the branding of “best” is valuable - presumably, through the indirect benefit of being able to appeal to customers as “the highest rated (by Mozilla) CA”. In practice, much like the CA/Browser Forum indirectly gave birth to the CA “Security” Council, or the existence of firms like Netcraft or NSS Labs, the more common outcome seems to be that if you don’t like the rules of the game you’re playing, you make up your own/redefine them and try to claim equivalency (much lol “alternative facts”). That is, I’m skeptical of approaches that attempt to say “most good,” because those seem to encourage all sorts of games of coming up with their own schemes, while “least bad” is more actionable - as “most bad” is more likely to receive sanctions. On Tue, Feb 6, 2018 at 10:03 PM Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Absolutely not. I view the competition as being based as the “most best”. > > > > You cannot get an “A” (or even A- or B+) without significantly exceeding > the minimum requirements, or demonstrating behaviors and practices that, > while not required, are behaviors Mozilla wants to encourage. > > > > Sticks are good. Carrots are tasty. > > > > -Tim > > > > Do you see the competition based on being the 'least bad' (i.e. more > likely to get an A because of no issues than a B because of some?) > > ___ > 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: Misissuance/non-compliance remediation timelines
Absolutely not. I view the competition as being based as the “most best”. You cannot get an “A” (or even A- or B+) without significantly exceeding the minimum requirements, or demonstrating behaviors and practices that, while not required, are behaviors Mozilla wants to encourage. Sticks are good. Carrots are tasty. -Tim Do you see the competition based on being the 'least bad' (i.e. more likely to get an A because of no issues than a B because of some?) 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
Misissuance/non-compliance remediation timelines
A bit over 5 months ago I reported a series of OCSP responders that were violating BRs (section 4.9.10) by returning GOOD on unknown serial numbers. Since that time the majority of those responder endpoints have been fixed, but several are still non-compliant; either with little communication or continuing assurances that it will be fixed "soon", where soon is a date that continuously slides into the future. At the moment Mozilla possesses very few options when it comes to punitive action and the lesson some CAs appear to be learning is that as long as you don't rise to PROCERT levels of malfeasance/incompetence then the maximum penalty is censure on bugzilla and email threads. Clearly this is not a deterrent. So, how long is too long? At what point should a CA incur consequences (and what form can those consequences take) for failure to remediate despite being given such immense latitude? As a straw man: what if we developed a set of technical constraints related to minimizing risk associated with CAs that are deemed to be acting poorly? For example, CAs deemed a risk would have their certificate maximum lifetime constrained to some amount less than the BRs currently allow. Additional penalties could include removal of EV trust indicators, constraining trust to a limited set of domains, marking contexts as insecure, and finally full distrust. Once a CA lands in a risk category further misissuance would escalate their risk to the community and thus incur additional constraints. (I'm sure the community can come up with far better tiers than I have!) Adding controls like this will require significant time and effort from Mozilla, but if we want to be able to manage the significant and ongoing volume of misissuance/non-compliance we're seeing I believe some level of granularity is needed. -Paul (reaperhulk) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
Yair, > Re Section 3.4, you seem to assume the domain holder is a ComSign > > subscriber. In case of misissuance, that may not be true. > >>> I understand, for that we added on the CPS on section 3.4 the > following: > "For the handling of revocation requests by other than the Subscriber or > his/her representative, refer to Section 4.9 below." > > Could you please explain how section 4.9 resolves this concern? My understanding of section 4.9 of your CPS is that only the Subscriber or an authorized representative may request revocation. > > >After reviewing the January Communication we have removed the > problematic > > > methods from our CPS entirely. > Thank you, this is a good change. However, it appears that you have made multiple modifications to your CPS without updating the version number or change log as required by Mozilla policy section 3.3. The latest version is dated January 31, 2018 but is still at version 4.1 as it was back in December. The software we are currently using is RSA CA 6.7 on Solaris. > As we mentioned we are now under audit on the new Microsoft CA and in the > process of moving to that software instead of our old software. > According to the link Ryan provided [1], this version lost extended support in July 2013. Is it correct that you have been using an unsupported version of CA system software for the past 4 1/2 years? Wayne [1] https://community.rsa.com/docs/DOC-73367 ___ 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
Below is the answer to the pointed out earlier. == Bad == * CPS docs are not assigned a version number (Mozilla policy 3.3) We had set up CP / CPS version number assignment rules. Based on this, at present CP / CPS Root version is Ver. 1.05 and CP / CPS Sub version is 1.07. We attached CP / CPS with version number. * I can’t find a current WebTrust for CAs audit statement - I've requested a translated copy in the bug. There may be confusion over the fact that two audits are required. Since the audit reports were posted on WebTrust's website as follows, we will report those URLs. WebTrust: https://cert.webtrust.org/ViewSeal?id=2385 SSLBR: https://cert.webtrust.org/ViewSeal?id=2386 * The translated WebTrust BR audit report does not include all the information required by Mozilla policy 3.1.4. Based on information in the bug I believe this meant to be a period-of-time audit, but it looks like a point-in time readiness audit. (Same as the above answer） Since the audit reports were posted on WebTrust's website as follows, we will report those URLs. WebTrust: https://cert.webtrust.org/ViewSeal?id=2385 SSLBR: https://cert.webtrust.org/ViewSeal?id=2386 == Meh == * Full name of the BRs is cut off in section 1: “CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly.” At the next revision, we will modify the corresponding part of CP / CPS section 1 of application CA 2 (Root) and application CA 2 (Sub) as follows. Application CA 2 (Root / Sub) conforms to the Baseline Requirements of CA / Browser Forum published at https://www.cabforum.org/. * Revision history doesn’t state what was changed (Mozilla policy 3.3 requires a “dated changelog” but doesn’t explicitly require a description of changes to be included) At the next revision, we will add a change history of application CA 2 (Root) and application CA 2 (Sub). * Neither the CPS or the BR Self Assessment explain how GPKI identifies high-risk certificate requests We have confirmed that the subjects of the server certificates are limited to "go.jp" and that those are the web servers managed by the government. In addition, we check the case of phishing on the websites such as the Council of Anti-Phishing Japan etc. and refer them to the examination work. * There are separate CPS’s for the root and it’s subordinate CA. Some of the required information (CAA, domain validation methods) is only contained in the sub CA’s CPS. Confirmation of CAA records, verification of domains, etc. are performed in the operation of application CA 2 (Sub), since it is being carried out in the application, not application CA 2 (Root), but application CA 2 (Sub). * The CPS doesn’t contain an explicit open-source license statement as encouraged by Mozilla policy 3.3(3) The CP / CPS document created by us has no special restrictions. * A minimal description of the methods used by the CA to perform domain authorization was added to section 4.1.2. How is method 3.2.2.4.1 used? I don’t think enough information is provided to comply with Mozilla policy 2. 2(3) that states “The CA's CP/CPS must clearly specify the procedure(s) that the CA employs”. However, the fact that this CA will be name constrained to go.jp reduces my concern over this. We are confirmed in the WHOIS database of Japan Registry Service that it matches domain owner. If it does not match, I will email the owner of the domain and check if this application is acceptable. Because we are also applicants of the government, we can operate it without problem with this method. * There are references to the “sterling committee” in the CPS. I believe this is meant to translate to “steering committee”. We have modified it with CP / CPS Root version Ver. 1.05 and CP / CPS Sub version 1.07. Thank you APCA 2017年12月22日金曜日 6時38分14秒 UTC+9 wth...@mozilla.com: > On Thursday, August 25, 2016 at 8:07:05 PM UTC, Kathleen Wilson wrote: > > > This request by the Government of Japan, Ministry of Internal > > > Affairs and Communications, is to include the GPKI 'ApplicationCA2 Root' > > > certificate and enable the Websites trust bit. This new root certificate > > > has been created in order to comply with the Baseline Requirements, and > > > will eventually replace the 'ApplicationCA - Japanese Government' root > > > certificate that was included via Bugzilla Bug #474706. Note that their > > > currently-included root certificate expires in 2017, and will be removed > > > via Bugzilla Bug #1268219. > > > > > > The request is documented in the following bug: > > > https://bugzilla.mozilla.org/show_bug.cgi?id=870185 > > > > Thank you to those of you who reviewed and commented on this request from > > Japan GPKI to include the GPKI 'ApplicationCA2 Root' certificate and enable > > the Websites trust bit. > > > > This discussion is on hold pending completion of the following action items > > by the CA: > > > > 1) Update the CP/CPS documents with
Re: Certificates with 2008 Debian weak key bug
On 6/02/2018 17:10, Ryan Sleevi wrote: The BRs actually seem to allow this, which at least looks like a bug in the BRs to me. It is allowed, and it's not a bug. It's specifically called out in 3.2.2 of the BRs. It seems that under 3.2.2.3 (b) they can just copy the ccTLD from the domain name, which seems rather useless to me. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificates with 2008 Debian weak key bug
On Tue, Feb 6, 2018 at 10:48 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 5/02/2018 17:08, Hanno Böck wrote: > >> https://crt.sh/?id=308392091=ocsp >> > > It has: > Subject: > commonName= ftp.gavdi.pl > countryName = PL > > This looks like a combination that's not allowed. Either it's domain > validated, in which case it should not have a countryName, or it should > contain other fields. > > The BRs actually seem to allow this, which at least looks like a bug in > the BRs to me. It would be very handy that the OIDs from the BRs where used > to indicate which validation was used. > It is allowed, and it's not a bug. It's specifically called out in 3.2.2 of the BRs. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate for com and it
On 6/02/2018 16:52, Kurt Roeckx wrote: On 6/02/2018 12:20, Hanno Böck wrote: Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is a subca of Baltimore Cybertrust, which belongs to Digicert. That certificate is revoked, not trusted by Mozilla or chrome. I should probably more clear, the certificates of the CA have been revoked. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificate for com and it
On 6/02/2018 12:20, Hanno Böck wrote: Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is a subca of Baltimore Cybertrust, which belongs to Digicert. That certificate is revoked, not trusted by Mozilla or chrome. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certificates with 2008 Debian weak key bug
On 5/02/2018 17:08, Hanno Böck wrote: https://crt.sh/?id=308392091=ocsp It has: Subject: commonName= ftp.gavdi.pl countryName = PL This looks like a combination that's not allowed. Either it's domain validated, in which case it should not have a countryName, or it should contain other fields. The BRs actually seem to allow this, which at least looks like a bug in the BRs to me. It would be very handy that the OIDs from the BRs where used to indicate which validation was used. It has: X509v3 Certificate Policies: Policy: 1.2.616.1.113527.2.5.1.9.6.3 That OID doesn't seem to be documented in the CPS. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Certificate for com and it
This certificate https://crt.sh/?id=282908507 is issued for the names "com" and "it". It also contains other suspicious hostnames: sip.fideuram sip.consule sip.consultant.fideura I don't think these TLDs exist. Issuer is "Intesa Sanpaolo CA Servizi Esterni Enhanced", which is a subca of Baltimore Cybertrust, which belongs to Digicert. Source: https://twitter.com/OhDearApp/status/960520419831894016 -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ComSign Root Renewal Request
On Monday, February 5, 2018 at 6:03:55 PM UTC+2, Julien Cristau wrote: > Re Section 3.4, you seem to assume the domain holder is a ComSign > subscriber. In case of misissuance, that may not be true. >>> I understand, for that we added on the CPS on section 3.4 the following: "For the handling of revocation requests by other than the Subscriber or his/her representative, refer to Section 4.9 below." > Cheers, > Julien > > On Mon, Feb 5, 2018 at 4:23 PM, YairE via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Hi, thank you for pointing the above > > Here is our response: > > > > Section 1.3.2.5 > > We have corrected our CPS now that only limited actions could be performed > > by DTP's > > And they cannot perform domain validation. > > > > Section 3.2.2.4 > > We are aware of the problems with the methods that have been raised, we > > thought that as long as they are permitted in the BR we would keep them > > included on our CPS, of course that we prefer not to use them and will use > > the more secured methods like 3.2.4.4.2, 3.2.4.4.3 etc. > > >After reviewing the January Communication we have removed the problematic > > methods from our CPS entirely. > > > > Section 3.2.2.8 > > As Ryan mentioned Comsign’s CAA identifier is documented on section > > 4.2.1.1(v) > > We also added it in section 3.2.2.8 now > > > > Section 3.4 > > I do not understand why does Ryan claim that a domain holder cannot > > request a revocation in case of misissuance, it clearly states that any > > subscriber could revoke any certificate for any reason he seems fit as long > > as they are identified. > > > > You can see all the updates on our CPS in our site repository: > > https://www.comsign.co.il/repository/ > > on our UK site: > > https://www.comsign.co.uk/?page_id=1282 > > and in this link as well: > > https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf > > > > Particularly Concerning > > The software we are currently using is RSA CA 6.7 on Solaris. > > As we mentioned we are now under audit on the new Microsoft CA and in the > > process of moving to that software instead of our old software. > > ___ > > 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: Validation Summit
Am Montag, 5. Februar 2018 22:31:46 UTC+1 schrieb Wayne Thayer: > Gerv and I have made, and the CA/Browser Forum has accepted a proposal to > convene a "Validation Summit" on Tuesday March 6th during the next > regularly scheduled CA/Browser Forum face-to-face meeting that will be held > in the Washington DC area. > > The intent of this summit is to perform an analysis of each of the "blessed > 10" domain validation methods, identify weaknesses, and determine if each > method needs to be improved or deprecated. You can find a proposed agenda > at [1]. > > The CA/Browser Forum has agreed to invite security experts who have > specialized knowledge of threat analysis and CA operations to participate, > and I would like to extend that invitation to members of the Mozilla > security community. It would be particularly helpful to have participants > who have experience in the following areas: > > > >1. Real-world experience with the validation procedures as they are >currently practiced by public CAs >2. Experience with threat modeling, analyzing a variety of protocols, or >other methods for rigorously analyzing processes and procedures for >potential vulnerabilities >3. Deep technical expertise related to how validation-related >technologies perform and/or fail in the real world (DNS, WHOIS, Domain >Registrars, Reverse IP lookup, and so on) >4. Technical challenges that prevent various validation methods from >being usable by a significant fraction of certificate applicants, and thus >drive users towards less desirable methods >5. Automation of validation protocols (i.e. ACME) > > Those putting their names forward should be prepared to adhere to the Code > of Conduct [2] and to participate in a constructive discussion that remains > focused on the topic at hand. If you would like to participate, you will be > required to become an Interested Party [3] and sign the CA/Browser Forum > IPR Agreement. [4] (Note: if your company is already a CA/Browser Forum > member, please check with your representative) > > If you intend to meet these requirements and attend the summit as an > Interested Party, please email me (wthayer-at-mozilla-dot-com) so that I > can get you added to the list of attendees and provide more information. > > We do expect to have a remote attendance option available; however, given > the size of the group, please be aware that it can be difficult to > participate even when the audio quality is good. If you would like to > attend in-person but require travel/accommodation sponsorship, please > mention that in your email to me, along with a ballpark figure for costs > (estimate the hotel as $122 per night). > > Wayne > > [1] https://cabforum.org/pipermail/public/2018-February/012908.html > [2] > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v.-1.7.pdf > (Exhibit C) > [3] https://cabforum.org/current-work > [3] https://cabforum.org/ipr-policy/ Hi Wayne, all, we really appreciate this effort to enable us all for a deep-dive into Validation mechanisms and how to proceed here. D-Trust will actively engage in this process and thus will be represented by Enrico Entschew and Arno Fiedler. Thanks, Kim ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
