Re: Logius PKIoverheid response to Action #2 in the January 2018 CA Communication

[Wayne Thayer via dev-security-policy]

Thank you for the response Jochem. I am glad to hear that Logius has
evaluated the risk and, given the passage of ballot 218, is moving to other
methods of domain validation.

- Wayne

On Fri, Mar 16, 2018 at 5:55 AM, Berge, J. van den (Jochem) - Logius via
dev-security-policy  wrote:

> Dear MSDP community,
>
> As requested by Mozilla in the CA Communication survey we've reviewed our
> implementation of BR 3.2.2.4.1 and 3.2.2.4.5. PKIoverheid only issues OV/EV
> certificates to subscribers for which the applicant representative has to
> have had a face-to-face check to confirm the identity of the representative
> (regardless of which method from 3.2.2.4 is used). The applicant
> representatives are defined beforehand by the applicant (authority is
> granted by a managing director, who's authority is checked against the
> national trade register). The issuing TSPs all use a secured environment in
> which the subscriber can order certificates. PKIoverheid certificates are
> mainly issued to Dutch subscribers. The Dutch Chamber of Commerce (de facto
> the national agency as referred in BR 3.2.2.1) only allows unique
> organization names, and as mentioned before, the TSP has a complete file of
> the applicant and it representative(s). In case that there is doubt about
> the authority of the applicant (whether us
>  ing method 3.2.2.4.1 or 3.2.2.4.5), another method from 3.2.2.4 is used
> instead. Therefore, the scenario as described earlier on the web (for
> instance, the Stripe, Inc. case) is, in our eyes, very unlikely. However,
> the PKIoverheid TSPs are now moving away from these methods per ballot 218.
>
> Please let me know if you have any questions.
>
>
> Kind regards,
>
> Jochem van den Berge
>
> Logius PKIoverheid
> Public Key Infrastructure for the Dutch government
> 
> Logius
> Ministry of the Interior and Kingdom Relations (BZK)
> Wilhelmina van Pruisenweg 52 | 2595 AN | The Hague
> PO Box 96810 | 2509 JE | The Hague
> 
> jochem.vanden.be...@logius.nl
> http://www.logius.nl
>
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u
> niet de geadresseerde bent of dit bericht abusievelijk aan u is
> toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht
> te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van
> welke aard ook, die verband houdt met risico's verbonden aan het
> elektronisch verzenden van berichten.
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. The State
> accepts no liability for damage of any kind resulting from the risks
> inherent in the electronic transmission of messages.
> ___
> 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: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[Ryan Sleevi via dev-security-policy]

On Thu, Mar 22, 2018 at 6:26 PM ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Ryan
> Many thanks for your report. I will try to answer to your concerns about
> our root inclusión.
>
> > In attempt to discuss continued trust, I have attempted to summarize the
> > patterns and issues of note, along with the timeline from reporting to
> > remediation. It is my goal that this will allow the public to make an
> > objective assessment of the risks introduced by Camerfirma, as well as
> the
> > responsiveness towards remediation. While the ecosystem continues to
> > improve both its understanding of the requirements and expectations, we
> > must nevertheless consider the full picture.
> >
> > Issue 1: Invalid dNSNames/CNs (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> > 2014-09-25 - https://crt.sh/?id=5129200=cablint issued
> > 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p
> > 2017-08-13 - Jonathan Rudenberg contacts the CA
> > 2017-08-16 - Kathleen Wilson opens a Bugzilla incident
> > 2017-08-17 - Camerfirma Responds
> > 2017-09 - Scheduled remediation
> > 2017-12 - First attempted remediation
> > 2018-02-14 - Actual remediation, as per
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33
> >
> > Issue 2: Unrevoked Internal Servernames (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> > 2016-10-01 - Deadline for revoking internal server name certificates
> > 2017-08-24 - Camerfirma shares list of misissued certificates affected by
> > Issue 1, along with their response
> > 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to identify
> and
> > revoke internal server name certificates -
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13
> > 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123=ocsp
> > 2017-11-28 - Gerv Markham highlights that Camerfirma has still not
> > responded to outstanding questions -
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21
> > 2017-12-21 - Camerfirma responds to the substance of the questions
> >
> > Issue 3 - Improperly Configured OCSP -
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
> > 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP
> > configurations at
> >
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g
> > 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance by
> > Camerfirma
> > 2017-12-22 - Camerfirma confirms the issue is resolved. It took one of
> > their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, to
> > implement these changes. Camerfirma did not self-report this
> > non-compliance, despite acknowledging it on 12-12.
> > 2018-01-03 - Camerfirma completes a minimal incident report with all
> > required information.
> >
> > Issue 4 - Improper CAA checking (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 )
> > 2017-09-08 - Baseline Requirements require checking CAA
> > 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by
> > Camerfirma
> > 2017-11-29 - Camerfirma confirms misissuance, believing it was valid
> > because they found "and for which CAA was checked" to be confusing and
> > indicating that CAA checking was optional.
> > 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs
> >
>
> All previous bugs as you said are closed successfully.
>
> >
> > Issue 5 - Duplicate dNSNames and invalid
> localityName/stateOrProvinceName (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
> > 2017-04-17 - Issue reported
> > 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The issue
> > is apparently a Camerfirma issue, and with improper logging as well as
> > certificate configuration.
> > 2017-10-13 - StartCom provides incident report, as a Camerfirma reseller
> > Note: No response was provided by Camerfirma in this incident report.
> >
> We were not aware that an answer from us was needed. The incident report
> provided by StartCom was coordinated with us.
> >
> > Issue 6 - Out of date CP/CPSes
> > 2016-06 - Last published version of the CPS at
> >
> http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf
> > 2018-05 - Next proposed update of the CPS, as stated elsewhere on this
> > thread
> >
> We already have a new CPS version, next week we will publish it, and a new
> version when it was RFC 3647 compliant.
>
> >
> > I'm not sure whether to track issues with the new hierarchy, so I will
> > simply note the following:
> > 2017-08-23 - Last issued certificate with invalid dNSName (
> >
> https://crt.sh/?caid=50473=cablint,zlint,x509lint=2011-01-01
> > )
> > 2017-12-13 - Last issued certificate that violates RFC 5280, 4.1.2.4's
> > requirements that "CAs conforming to this profile MUST use either the
> > PrintableString or UTF8String encoding of DirectoryString, with two
> > exceptions" (
> https://crt.sh/?cablint=261=50473=2011-01-01 )
> >
> there is an open bug 

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

[ramirommunoz--- via dev-security-policy]

Hi Ryan
Many thanks for your report. I will try to answer to your concerns about our 
root inclusión.

> In attempt to discuss continued trust, I have attempted to summarize the
> patterns and issues of note, along with the timeline from reporting to
> remediation. It is my goal that this will allow the public to make an
> objective assessment of the risks introduced by Camerfirma, as well as the
> responsiveness towards remediation. While the ecosystem continues to
> improve both its understanding of the requirements and expectations, we
> must nevertheless consider the full picture.
> 
> Issue 1: Invalid dNSNames/CNs (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> 2014-09-25 - https://crt.sh/?id=5129200=cablint issued
> 2017-08-12 - Jonathan Rudenberg posts to m.d.s.p
> 2017-08-13 - Jonathan Rudenberg contacts the CA
> 2017-08-16 - Kathleen Wilson opens a Bugzilla incident
> 2017-08-17 - Camerfirma Responds
> 2017-09 - Scheduled remediation
> 2017-12 - First attempted remediation
> 2018-02-14 - Actual remediation, as per
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c33
> 
> Issue 2: Unrevoked Internal Servernames (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977 )
> 2016-10-01 - Deadline for revoking internal server name certificates
> 2017-08-24 - Camerfirma shares list of misissued certificates affected by
> Issue 1, along with their response
> 2017-08-24 - Ryan Sleevi highlights that Camerfirma failed to identify and
> revoke internal server name certificates -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c13
> 2017-09-12 - Camerfirma revokes https://crt.sh/?id=8680123=ocsp
> 2017-11-28 - Gerv Markham highlights that Camerfirma has still not
> responded to outstanding questions -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1390977#c21
> 2017-12-21 - Camerfirma responds to the substance of the questions
> 
> Issue 3 - Improperly Configured OCSP -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1426233
> 2017-12-12 - Rob Stradling reports on CA's improperly configured OCSP
> configurations at
> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/C2vTpvouP3g
> 2017-12-19 - Wayne Thayer opens a bug regarding OCSP non-conformance by
> Camerfirma
> 2017-12-22 - Camerfirma confirms the issue is resolved. It took one of
> their sub-CAs from 12-12 to 12-19, and another from 12-12 to 12-22, to
> implement these changes. Camerfirma did not self-report this
> non-compliance, despite acknowledging it on 12-12.
> 2018-01-03 - Camerfirma completes a minimal incident report with all
> required information.
> 
> Issue 4 - Improper CAA checking (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1420871 )
> 2017-09-08 - Baseline Requirements require checking CAA
> 2017-11-27 - Quirin Scheitle reports CAA checking non-compliance by
> Camerfirma
> 2017-11-29 - Camerfirma confirms misissuance, believing it was valid
> because they found "and for which CAA was checked" to be confusing and
> indicating that CAA checking was optional.
> 2017-11-29 - Camerfirma claims CAA checking is activated on all RAs
>

All previous bugs as you said are closed successfully.

> 
> Issue 5 - Duplicate dNSNames and invalid localityName/stateOrProvinceName (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1357067 )
> 2017-04-17 - Issue reported
> 2017-04-20 - Camerfirma reports the issue is fixed to StartCom. The issue
> is apparently a Camerfirma issue, and with improper logging as well as
> certificate configuration.
> 2017-10-13 - StartCom provides incident report, as a Camerfirma reseller
> Note: No response was provided by Camerfirma in this incident report.
> 
We were not aware that an answer from us was needed. The incident report 
provided by StartCom was coordinated with us.
>
> Issue 6 - Out of date CP/CPSes
> 2016-06 - Last published version of the CPS at
> http://docs.camerfirma.com/publico/DocumentosWeb/politicas/CPS_V_3_2_7_EN.pdf
> 2018-05 - Next proposed update of the CPS, as stated elsewhere on this
> thread
> 
We already have a new CPS version, next week we will publish it, and a new 
version when it was RFC 3647 compliant.

>
> I'm not sure whether to track issues with the new hierarchy, so I will
> simply note the following:
> 2017-08-23 - Last issued certificate with invalid dNSName (
> https://crt.sh/?caid=50473=cablint,zlint,x509lint=2011-01-01
> )
> 2017-12-13 - Last issued certificate that violates RFC 5280, 4.1.2.4's
> requirements that "CAs conforming to this profile MUST use either the
> PrintableString or UTF8String encoding of DirectoryString, with two
> exceptions" ( https://crt.sh/?cablint=261=50473=2011-01-01 
> )
>
there is an open bug https://bugzilla.mozilla.org/show_bug.cgi?id=1443857 where 
previous bug are treated.

> 
> Notable is that Camerfirma includes the organizationIdentifier,
> OID 2.5.4.97, in their certificates. This is documented in the CPS [5] from
> the original message, within Section 3.1.1, with the validation process
> described in 

RE: DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Jeremy Rowley via dev-security-policy]

True. I can tell you our process was not followed in this case, primarily 
because of the Symantec transaction.



Ideally, when we add new products (or when a CAB Forum requirement changes), 
we:

1.  Add the mandatory criteria to our compliance engine
2.  Add the new cert to our issuing CA
3.  Add the validation requirements in validation service
4.  Train the staff on the new product/service
5.  Enable access via the API and GUI



For the most part compliance takes place in two areas (in our updated system). 
First in the compliance engine for all things technical. Second in the 
validation service for all validation requirements. On the onion cert issue, 
we only did #2 and #4.



From: dev-security-policy 
 On 
Behalf Of Nick Lamb via dev-security-policy
Sent: Thursday, March 22, 2018 9:31 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert .onion certificates without Tor Service Descriptor Hash 
extension



On 21 Mar 2018 17:58, Wayne Thayer via dev-security-policy 
 > wrote:

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.

We revoked the certificates and added preliminary checking for Tor
descriptors. We are adding additional checks to ensure certs cannot
issue without them.



A broader consideration might be how DigiCert (or any CA) can ensure such 
checks get thought up / planned for during the process of spinning up a new 
type of issuance.

Imagine the CA/B eventually authorizes some hypothetical new "MV" 
certificates, they are Web PKI certs but with some different (less / more / 
just strange) validation and criteria for the cert itself. Obviously we cannot 
plan today for how this should be done exactly, but a CA thinking of issuing 
MV ought to - as part of that - figure out what needs to happen in terms of 
preventing mis-issuance of the new certs.

Otherwise we're inevitably back here shortly after the CA/B says OK.



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: DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Nick Lamb via dev-security-policy]

On 21 Mar 2018 17:58, Wayne Thayer via dev-security-policy	  wrote: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.



We revoked the certificates and added preliminary checking for Tor

descriptors. We are adding additional checks to ensure certs cannot

issue without them.A broader consideration might be how DigiCert (or any CA) can ensure such checks get thought up / planned for during the process of spinning up a new type of issuance.Imagine the CA/B eventually authorizes some hypothetical new "MV" certificates, they are Web PKI certs but with some different (less / more / just strange) validation and criteria for the cert itself. Obviously we cannot plan today for how this should be done exactly, but a CA thinking of issuing MV ought to - as part of that - figure out what needs to happen in terms of preventing mis-issuance of the new certs.Otherwise we're inevitably back here shortly after the CA/B says OK.___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy