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
D-Trust certificates with ROCA fingerprints
Hi all, Rob posted a list containing D-Trust certificates showing a ROCA fingerprint today at https://misissued.com/batch/28/ We are treating this as an incident although all the mentioned D-Trust related certificates are Qualified CAs governed by national German law and therefore are not related to WebPKI, i.e. are not chaining up to roots trusted by NSS. An incident report will by provided by noon Thursday, 2017/10/19 German time. No WebPKI related systems within D-Trust are affected by the weak RSA key generation issue as announced this week. Regards, Kim Nguyen (D-Trust) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ROCA fingerprints found on crt.sh (was Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards)
Hi Rob, all, we are treating this as an incident although all certs related to D-Trust are indeed Qualified/EUTL certs governed by National German Law and are not chaining up to roots that trusted by NSS, hence are not related to the WekbPKI. An incident report will be submitted by tomorrow noon (Thursday, 2017/10/19, German time). None of the systems used within D-Trust to operate WebPKI CAs are affected by the weak RSA key generation topic reported today. Kim Nguyen, D-Trust ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: ROCA fingerprints found on crt.sh (was Re: Efficient test for weak RSA keys generated in Infineon TPMs / smartcards)
Am Mittwoch, 18. Oktober 2017 11:15:03 UTC+2 schrieb Rob Stradling: > I've completed a full scan of the crt.sh DB, which found 171 certs with > ROCA fingerprints. > > The list is at https://misissued.com/batch/28/ > > Many of these are Qualified/EUTL certs rather than anything to do with > the WebPKI. Only about half of them chain to roots that are trusted by NSS. > > On 17/10/17 14:49, Rob Stradling via dev-security-policy wrote: > > On 16/10/17 23:15, Jakob Bohm via dev-security-policy wrote: > > > >> Unfortunately, as of right now, their github repository still doesn't > >> include the promised C/C++ implementation, > > > > Hi Jakob. Today I ended up rewriting the ROCA fingerprint checker in C > > (using OpenSSL BIGNUM calls) to get it working in crt.sh. In case it's > > useful, here's a Gist: > > > > https://gist.github.com/robstradling/f525d423c79690b72e650e2ad38a161d > > > > Build it with -lcrypto and pipe a DER cert to STDIN > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online Hi Rob, all, we are regarding this as an incident although all D-Trust related certificates are Qualified/EUTL certs governed by national German law as noted by Rob and are chaining up to roots that are trusted by NSS. Nevertheless an incident report will be provided tomorrow (2017/10/19). Kim Nguyen, D-Trust ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CAs not compliant with CAA CP/CPS requirement
Am Freitag, 8. September 2017 21:25:20 UTC+2 schrieb Andrew Ayer:
> The BRs state:
>
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate
> Policy and/or Certification Practice Statement (section 4.1 for CAs
> still conforming to RFC 2527) SHALL state the CA's policy or practice
> on processing CAA Records for Fully Qualified Domain Names; that policy
> shall be consistent with these Requirements. It shall clearly specify
> the set of Issuer Domain Names that the CA recognises in CAA 'issue' or
> 'issuewild' records as permitting it to issue. The CA SHALL log all
> actions taken, if any, consistent with its processing practice."
>
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes
> of some CAs.
>
> At time of writing, the latest published CP/CPSes of the following CAs
> are not compliant with the above provision of the BRs:
>
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
>
> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
> specify issuer domain names
>
> DigiCert (https://www.digicert.com/legal-repository/) - Does not
> specify issuer domain names, and processing is not compliant with BRs
> ("If a CAA record exists that does not list DigiCert as an authorized
> CA, DigiCert verifies that the applicant has authorized issuance,
> despite the CAA record.")
>
> Google Trust Services (https://pki.goog/) - Does not check CAA
>
> Identrust (https://secure.identrust.com/certificates/policy/ts/) -
> Does not check CAA
>
> Izenpe
> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certificados/es_url/index.shtml)
> - Does not specify issuer domain names
>
> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA
>
> Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
>
> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) -
> No mention of CAA
>
> Visa (http://www.visa.com/pki/) - Does not check CAA
>
>
> These CAs have compliant CP/CPSes:
>
> Entrust
>
> GlobalSign
>
> GoDaddy
>
> Let's Encrypt
>
> QuoVadis
>
> Trustwave
>
>
> It would be nice to hear confirmation from the non-compliant CAs that they
> really are checking CAA as required, and if so, why they overlooked the
> requirement to update their CP/CPS.
>
> Regards,
> Andrew
Dear all,
we can confirm that D-Trust is also performing CAA as required, the updated
CA/CPS is currently under Review with our conformity assessment Body and will
be published as soon as possible.
Regards, Kim
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Re: dNSName containing '/' / low serial number entropy
Am Mittwoch, 19. Juli 2017 00:26:16 UTC+2 schrieb Charles Reiss:
> https://crt.sh/?id=174827359 is a certificate issued by D-TRUST SSL
> Class 3 CA 1 2009 containing the DNS SAN
> 'www.lbv-gis.brandenburg.de/lbvagszit' (containing a '/') with a
> notBefore in April 2017.
>
Regarding this Topic, this incorpates the D-Trust PostMortem,
Remidiation and Revocation Status. Regards, Kim
Issue dNSName containing '/', https://crt.sh/?id=174827359
PostMortem:
An incident was triggered by a bug in mozilla.dev.security.policy 07-08-2017.
Issuance was stopped immediately at 07-08-2017
Analysis yielded the following results:
Validation is based on both a four-eyed principle “human” approach as well as a
tool based automated validation.
The GUI of our validation software backend which our team is using had some
usability and visualization related issues. This implied that the way multiple
SANs were displayed had potential for mistakes. We released the improvement of
the backend GUI on the 2017-08-24 as previously announced.
The bug mentioned with respect to the CSR Validator was that the CSR validator
didn’t filter prohibited characters correctly and was introduced by the
previous release but was not recognized during test.
Mitigation/Remediation:
Existing Mitigations: Certificates require two independent parties to approve
("four eyes principle")
Remediation:
2017-08-15 - The Certificate was revoked
2017-08-24 - Hotfix to systems to validate CSR against RFC 5280
2017-08-24 - Hotfix to update validation software UI to reduce risk of mistakes
2018-03-31 - Improved software testing to consider such cases
In order to enhance the quality assurance during issuance we are setting up
both manual random checks as well as automated compliance checks in our
issuance system.
Also a case-related awareness training was performed.
Revocation plan:
The cert was revoked, a new BR compliant cert was issued for the costumer
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
