Re: Summary of Camerfirma's Compliance Issues

[Matthias van de Meent via dev-security-policy]

On Tue, 26 Jan 2021 at 16:28, Ramiro Muñoz via dev-security-policy
 wrote:
>
> El lunes, 25 de enero de 2021 a las 13:31:18 UTC+1, Matthias van de Meent 
> escribió:
> > On Sun, 24 Jan 2021 at 20:58, Ramiro Muñoz via dev-security-policy
> >  wrote:
> > >
> > > Thanks everyone for your valuable contribution to the discussion. We’ve 
> > > prepared a throughful Remediation Plan that addresses all areas of 
> > > improvement emerged both in this public discussion as well as direct 
> > > contacts with some of the members 
> > > https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing.
> > >  The plan is very ambitious but, we’ve our BoD commitment to align 
> > > Camerfirma to the highest level of standards of the Mozzilla community. 
> > > Please feel free send us any request for clarification or any suggestion 
> > > to improve the attached document.
> > In one of your previous replies on this thread you stated the following:
> >
> > > . We are rethinking the SubCA policy since some of the problems come from 
> > > there. Camerfirma has increase the control imposing our 3 external SubCA 
> > > to use the camerfirma central lint control in the pre-isuance process. 
> > > However, next year we plan to convert external SubCA to Wite label CA, 
> > > that's means to run them inside Camerfirma infrastructure.
> >
> > But in this document it looks like this decision has been reverted:
> >
> > > a. Action Point 10.
> > > Insource the management of all the operational activities of the 
> > > intermediate CAs (June
> > 2021).
> > > How:
> > > - Obligation of the SubCA to use the application of controls defined by 
> > > Camerfirma (obligation to send us evidence that they have implemented 
> > > them).
> > > - SubCA obligation to submit to audits set by Camerfirma and with an 
> > > auditor selected by Camerfirma.
> > > - Insource management of all the operational activities of the 
> > > intermediate CAs in a discretionary manner.
> > >
> > > Resources: Internal resources (Legal).
> >
> > Specifically, the need for SubCAs to submit to audits implies that
> > this SubCA (company) is still in control of the ICA's signing.
> > Additionally, the lack of operational resources required for this
> > change further reinforces this implication.
> >
> > As we've seen a lot of problems also stemming from the implementation
> > of external SubCAs, this seems like a serious deterioration in
> > trustability, as that requires Mozilla to trust Camerfirma to hold the
> > SubCA to the requirements of the relevant root stores, while it has
> > repeatedly shown not to do that.
> >
> > Could you explain why you decided to revert that decision?
> >
> > Regards,
> >
> > Matthias van de Meent
>
> Dear Matthias;
>
> We’ve had the chance to discuss the topic with some of our subCAs and arrived 
> to the proposed solution.
> What we’re proposing is not an immediate insourcing of all SubCAs operational 
> activities but, a right to do so if and when we deem it necessary.
> This means the following:
>
> 1.  SubCAs will be obliged to implement the application controls defined 
> by Camerfirma
> 2.  SubCAs will be obliged to submit to audits set by Camerfirma and with 
> an auditor selected by Camerfirma
> 3.  SubCAs will accept contractually that Camerfirma can at any time 
> decide to gain full control of their operational activities
>
> In such a way we’ll be able,  at any timer, to insource the management of 
> operational activities of our ‘problematic’ intermediate CA.
> While virtuous intermediate CA will be allowed to retain the control of their 
> operational activities as long as they remain virtuous.

Could you share what your definition of 'virtuous' means? This, too,
is critical in determining if the trust in your actions (including
your actions to keep trusting these SubCAs with key, operational and
managemental control of parts of your CA infrastructure) is misplaced
or not. And since your SubCAs have a less than virtuous track record,
this wording seems out-of-place.


> In addition, In our remediation plan we are going to incorporate additional 
> resources and controls that will allow us to carry out this monitoring with 
> all guarantees.
> However, we are open to discuss further tuning of our remediation plan to 
> gain the community confident and  assure the security and compliance with the 
> BRs and Mozilla's policies.
> ___
> 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: Mozilla's Response to Camerfirma's Compliance Issues

[Matthias van de Meent via dev-security-policy]

On Tue, 26 Jan 2021 at 06:21, Ben Wilson via dev-security-policy
 wrote:
>
> - Do the proposed actions in the Remediation Plan address the underlying
> issues?

One of the underlying issues is that Camerfirma has multiple SubCAs
with each their own control over ICA keys, CPS, certificate profiles,
conformance and validation. As the proposed plan doesn't seem to
remove all of those (reasons mentioned in the other thread), I do not
think this Remediation Plan addresses that part of the concern.

> - If Camerfirma fully executes on this plan, will that be sufficient to
> regain trust so that they can remain a CA in Mozilla's root store?

I find it difficult to trust in a CA that supplies other companies
with unconstrained ICAs. One CA can have a few classes of problems,
but now we have one CA which has their own classes of problems, plus
the problems of their SubCAs.

As we've seen before, and probably will continue to see in the future;
unconstrained SubCAs that are not direct part of a root program are an
antipattern for public trust. It can provide a false impression of
"the CA didn't make the mistake, the SubCA did", whereas the mistakes
of the SubCA _are_ the mistakes of the CA due to the delegation of
trust by the CA to the SubCA; any mistakes made by that SubCA
(trust-wise) are the mistakes of the CA as long as the SubCA is valid.

I have not seen much improvement in communication, self-reporting and
problem resolving of problems with regards to Camerfirma's SubCAs, nor
have I seen substantial improvements in Camerfirmas' stance regarding
their SubCAs. If this was only about the CA activities of Camerfirma
(excluding the SubCAs), the improvements would scrape the bottom, but
the existence of externally managed SubCAs more than triple the risks
involved.

> - Do you have additional recommendations for steps that you think
> Camerfirma should take?

- Stop using the current roots / request removal of current roots /
revoke all external SubCAs.
- Start a new root of trust (the current roots are 'poisoned' due to
the delegated OCSP responder issue and missing key destruction audits
of some of said OCSP responder keys).
- Operate all of the CA infrastructure of this new root of trust
without delegating any of keys, management, validation, and operations
to SubCAs.
- Ensure that you comply to the BR and relevant root store policies
and that you can respond to problems promptly.
- Then, and only then, request inclusion of the new root(s) into the
relevant root stores.

Regards,

Matthias van de Meent
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Summary of Camerfirma's Compliance Issues

[Matthias van de Meent via dev-security-policy]

On Sun, 24 Jan 2021 at 20:58, Ramiro Muñoz via dev-security-policy
 wrote:
>
> Thanks everyone for your valuable contribution to the discussion. We’ve 
> prepared a throughful Remediation Plan that addresses all areas of 
> improvement emerged both in this public discussion as well as direct contacts 
> with some of the members 
> https://drive.google.com/file/d/1DV7cUSWqdOEh3WwKsM5k1U5G4rT9IXog/view?usp=sharing.
>  The plan is very ambitious but, we’ve our BoD commitment to align Camerfirma 
> to the highest level of standards of the Mozzilla community. Please feel free 
> send us any request for clarification or any suggestion to improve the 
> attached document.

In one of your previous replies on this thread you stated the following:

> .   We are rethinking the SubCA policy since some of the problems come 
> from there. Camerfirma has increase the control imposing our 3 external SubCA 
> to use the camerfirma central lint control in the pre-isuance process.  
> However, next year we plan to convert external SubCA to Wite label CA, that's 
> means to run them inside Camerfirma infrastructure.

But in this document it looks like this decision has been reverted:

> a. Action Point 10.
> Insource the management of all the operational activities of the intermediate 
> CAs (June
2021).
> How:
> - Obligation of the SubCA to use the application of controls defined by 
> Camerfirma (obligation to send us evidence that they have implemented them).
> - SubCA obligation to submit to audits set by Camerfirma and with an auditor 
> selected by Camerfirma.
> - Insource management of all the operational activities of the intermediate 
> CAs in a discretionary manner.
>
> Resources: Internal resources (Legal).

Specifically, the need for SubCAs to submit to audits implies that
this SubCA (company) is still in control of the ICA's signing.
Additionally, the lack of operational resources required for this
change further reinforces this implication.

As we've seen a lot of problems also stemming from the implementation
of external SubCAs, this seems like a serious deterioration in
trustability, as that requires Mozilla to trust Camerfirma to hold the
SubCA to the requirements of the relevant root stores, while it has
repeatedly shown not to do that.

Could you explain why you decided to revert that decision?

Regards,

Matthias van de Meent
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FNMT: Public Discussion of Root Inclusion Request

[Matthias van de Meent via dev-security-policy]

Thanks for the pointer, Ben.

I didn't realise that the links in section 'Particulares AC Raíz
FNMT-RCM Servidores Seguros' of their main repository [1] were links
to repositories that would include the applicable CPS... As those
sections seemed to be for ICAs of the root, I didn't consider them as
a source for the CPS of their parent CA. Together with that the CPS
pointers in the certificate profile point to the main repository and
that the QcPDS links in the certificate profiles don't seem to point
to anything, I got lost...

So, sorry for the noise, I was very confused by the structure of the repository.

Now that I know where to look, I'll probably check the contents more
thoroughly sometime in the following weekend, at first glance they
already looked much better.

-Matthias

[1] 
https://www.sede.fnmt.gob.es/en/normativa/declaracion-de-practicas-de-certificacion

On Wed, 2 Dec 2020, 23:44 Ben Wilson,  wrote:
>
> Matthias,
> Have you been able to obtain the CPS downloadable from here:
> https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1  or here:  
> https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2  ?  (They 
> both lead to the same CPS v. 1.6 document.)
> Ben
>
> On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via dev-security-policy 
>  wrote:
>>
>> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> >
>> > El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias van de
>> Meent escribió:
>> > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
>> > >  wrote:
>> > > >
>> > > > [...]
>> > > >
>> > > > *CP/CPS:*
>> > > >
>> > > >
>> https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
>> > > >
>> > > > Current CPS is version 1.5, published 1-October-2020.
>> > > >
>> > > > Repository location:
>> > > >
>> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
>> > > >
>> > > I'm having trouble finding the end entity certificate profiles in this
>> > > CPS. According to the CPS s7.1.2, they are supposed to be available at
>> > > http://www.cert.fnmt.es/dpcs/, but that redirects me to a repository
>> > > [0] of which the only english-language document [1] does not contain
>> > > any end entity certificate profiles, but only the root and ICA
>> > > profiles in attachments. Similarly, I cannot find the CPS you linked
>> > > in their repository.
>> > >
>> > All the relevant documentation (CPS, PDS, Terms and conditions,
>> certificate profiles, and old versions of CPSs) of each CA is published in
>> its corresponding channel in the website, all of them accessible from:
>> >
>> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
>>
>> I'm sorry, but I'm having trouble finding a link to the latest version of
>> the CPS of the to-be-included root in that repository. If you add this CPS,
>> it would be useful to take Mozilla Root Store Policy section 3.3 (6) into
>> account ("CAs must provide a way to clearly determine which CP and CPS
>> applies to each of its root and intermediate certificates").
>>
>> > For AC RAIZ FNMT-RCM SERVIDORES SEGUROS we have 2 channels (one for each
>> intermediate CA):
>> > AC SERVIDORES SEGUROS TIPO 1:
>> > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1
>> > and
>> > AC SERVIDORES SEGUROS TIPO 2:
>> > https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
>> >
>> > In regards the certificate profiles, we have included in CPS v1.6 section
>> 7.1.2. direct links to the published documents of profiles.
>> >
>> > The document describing the profiles of the Website authentication
>> certificates, including all extensions, are published at
>> > AC SERVIDORES SEGUROS TIPO 1:
>> >
>> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
>> > AC SERVIDORES SEGUROS TIPO 2:
>> >
>> https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf
>> >
>>
>> Thank you for the links, I probably overlooked them before.
>>
>> > > I noticed that the CPS defers a great amount of sections (section 5,
>> > > 6.2, 6.4, 8.2 - 8.7 and large parts of section 9) to the DGPC, which
>> > > pr

Re: FNMT: Public Discussion of Root Inclusion Request

[Matthias van de Meent via dev-security-policy]

On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias van de
Meent escribió:
> > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
> >  wrote:
> > >
> > > [...]
> > >
> > > *CP/CPS:*
> > >
> > >
https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
> > >
> > > Current CPS is version 1.5, published 1-October-2020.
> > >
> > > Repository location:
> > >
https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
> > >
> > I'm having trouble finding the end entity certificate profiles in this
> > CPS. According to the CPS s7.1.2, they are supposed to be available at
> > http://www.cert.fnmt.es/dpcs/, but that redirects me to a repository
> > [0] of which the only english-language document [1] does not contain
> > any end entity certificate profiles, but only the root and ICA
> > profiles in attachments. Similarly, I cannot find the CPS you linked
> > in their repository.
> >
> All the relevant documentation (CPS, PDS, Terms and conditions,
certificate profiles, and old versions of CPSs) of each CA is published in
its corresponding channel in the website, all of them accessible from:
>
https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion

I'm sorry, but I'm having trouble finding a link to the latest version of
the CPS of the to-be-included root in that repository. If you add this CPS,
it would be useful to take Mozilla Root Store Policy section 3.3 (6) into
account ("CAs must provide a way to clearly determine which CP and CPS
applies to each of its root and intermediate certificates").

> For AC RAIZ FNMT-RCM SERVIDORES SEGUROS we have 2 channels (one for each
intermediate CA):
> AC SERVIDORES SEGUROS TIPO 1:
> https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-1
> and
> AC SERVIDORES SEGUROS TIPO 2:
> https://www.sede.fnmt.gob.es/en/dpcs/ac-servidores-seguros-tipo-2
>
> In regards the certificate profiles, we have included in CPS v1.6 section
7.1.2. direct links to the published documents of profiles.
>
> The document describing the profiles of the Website authentication
certificates, including all extensions, are published at
> AC SERVIDORES SEGUROS TIPO 1:
>
https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo1.pdf
> AC SERVIDORES SEGUROS TIPO 2:
>
https://www.sede.fnmt.gob.es/documents/10445900/10575386/Perfiles_certificados_servidores_seguros_tipo2.pdf
>

Thank you for the links, I probably overlooked them before.

> > I noticed that the CPS defers a great amount of sections (section 5,
> > 6.2, 6.4, 8.2 - 8.7 and large parts of section 9) to the DGPC, which
> > probably is [1] but that is never explicitly confirmed in the CPS -
> > there is no explicit link to any repository in section 1.6.1 where the
> > acronym is defined, nor are there any other indications that this DGPC
> > is located in the repository under the link of [0]. This is confusing,
> > and detrimental to the readability of the document.
> >
> CPS new version (v1.6) integrates all the sections that were referred to
in the DGPC (v5.8) and which applied in general to all our CAs. From
version 1.6 our CPS collects in a single document all the information and
BRs compliance commitments for our AC RAIZ FNMT-RCM SERVIDORES SEGUROS
> [...]
> I hope that we have been able to resolve all the issues raised with this
new version of the CPS (1.6) and have gained in transparency.
> Thanks
> Santiago.

Thanks for the update, it sounds promising. I'll check it again once I can
find the CPS in the repository.

Regards,

Matthias
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: FNMT: Public Discussion of Root Inclusion Request

[Matthias van de Meent via dev-security-policy]

On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy,
 wrote:
>
> All,
>
> This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process for Fábrica Nacional de Moneda y Timbre
> (FNMT)’s request to include the AC RAIZ FNMT-RCM SERVIDORES SEGUROS in the
> root store. See
> https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
> through 9).
>
> Mozilla is considering approving FNMT’s request to add the root as a trust
> anchor with the websites trust bit and EV enabled as documented in Bugzilla 
> bug
> #1559342 .
>
> This email begins the 3-week comment period, after which, if no concerns
> are raised, we will close the discussion and the request may proceed to the
> approval phase (Step 10).
>
> [...]
>
> *CP/CPS:*
>
> https://www.sede.fnmt.gob.es/documents/10445900/10536309/dpc_ss_english.pdf
>
> Current CPS is version 1.5, published 1-October-2020.
>
> Repository location:
> https://www.sede.fnmt.gob.es/normativa/declaracion-de-practicas-de-certificacion
>

I'm having trouble finding the end entity certificate profiles in this
CPS. According to the CPS s7.1.2, they are supposed to be available at
http://www.cert.fnmt.es/dpcs/, but that redirects me to a repository
[0] of which the only english-language document [1] does not contain
any end entity certificate profiles, but only the root and ICA
profiles in attachments. Similarly, I cannot find the CPS you linked
in their repository.

I noticed that the CPS defers a great amount of sections (section 5,
6.2, 6.4, 8.2 - 8.7 and large parts of section 9) to the DGPC, which
probably is [1] but that is never explicitly confirmed in the CPS -
there is no explicit link to any repository in section 1.6.1 where the
acronym is defined, nor are there any other indications that this DGPC
is located in the repository under the link of [0]. This is confusing,
and detrimental to the readability of the document.

CPS s4.9.2 and s1.5.2 both mention that third parties may send
certificate problem reports, and select parties may send revocation
requests, which is great; but I cannot find a commitment to
communicating a preliminary report within 24 hours to the reporter as
stipulated by BR 4.9.5.

CPS / DGPC s5.2.2 includes by reference an internal policy, which may
or may not comply with the "at least dual control for CA private key
backup/storage/recovery" requirement of BR 5.2.2.

CPS / DGPC s5.3.1 only guarantee the "experience and knowledge", not
the "trustworthiness and identity" of the operators.

CPS / DGPC s5.3.3 does not provide information on the specific topics
that are SHALL-qualified in BR s5.3.3. This same can be said about
s5.3.4 and s5.3.7.

CPS / DGPC s5.4.1 does definately not mention logging
rejection/acceptance of certificate requests (BR s5.4.1(1)(3)), and
probably also doesn't cover some other parts, but the language is very
opaque (i.e. unclear).
... looks further
... those specific events are apparently included in 5.5.1 Types of
Records Archived (?)

CPS / DGPC s5.4.3 does not comply with BR 5.4.3: Audit log retention
of 15 years is not enough to cover the CA certificate event record log
retention timespan of 2 years past the latest of 1.) the destruction
of the CA private key, and 2.) the revocation or expiration of the
final CA certificate of that private key. Unless of course you expect
to revoke the root and destroy the CA keys within 13 years after
creation.

CPS / DGPC s6.1.1.1 (CA Key Pair Generation) fails to include the
procedure with which CA keys are generated.
More specifically, the current implication is that the auditor could
not be witness of the CA key generation ceremony, nor have seen any
evidence other than the report, and sign this report. This fails to
apply BR 6.1.1.1(1) items 2 and 3, and BR 6.1.1.1(2)(2). The procedure
included by reference is not accessible [3] and may add requirements,
but those requirements need not meet the baseline of the BR.

CPS s6.2 points to a section s6.2 in the DGPC, which is blank.
Therefore, I'm missing the documentation on that the CA is committed
to securing the CA private key material in a BR-compliant manner.

CPS / DGPC s6.2.4 does not apply the requirements of BR 6.2 nor 5.2.2
to their private key backup procedure.

CPS delegates s6.2.5 fully to the DGPC, but that s6.2.5 requires the
CPS to at least specify a maximum number of copies of the private key,
which is not specified.

CPS / DGPC s6.2.6 has the interesting construction "Consequently, the
Keys cannot be transferred, although there is a recovery procedure",
which implies a procedure to extract and transfer keys exists.

CPS / DGPC s6.2.7 fails to commit FNMT to using devices meeting FIPS
140 level 3 or higher (as that is apparently located in DGPC 6.2.1 and
6.2.8 (?))

CPS / DGPC does not mention "factor" or "2fa" according to my search,
even though BR 6.5.2 specifies 'The CA SHALL enforce multi-factor

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

[Matthias van de Meent via dev-security-policy]

On Fri, 23 Oct 2020 at 17:33, Ryan Sleevi  wrote:
>
> On Fri, Oct 23, 2020 at 8:55 AM Matthias van de Meent via dev-security-policy 
>  wrote:
>>
>> The current MRSP do not bind the requirements on the reporting of
>> incidents to the CA that the incident was filed on, but generally to
>> CAs.
>>
>> Section 2.4 has the general requirement for a CA to report any
>> incident (which is a failure to comply with the MRSP by any CA). So,
>> if a CA is aware of an incident with another CA which is included in
>> the Mozilla root store, that must be reported, and I agree with that.
>
>
> This sounds like an overly broad reading of Mozilla Policy, and it's not 
> clear to me how you reached it. Could you walk me through the language and 
> help me understand how you reached that conclusion?

Section 2.4 specifies an incident as 'when _a_ CA fails to comply with
any requirement of this policy'. So, an incident is any CA having a
problem.
The next sentence reads that "At a minimum, CAs MUST promptly report
all incidents to Mozilla ...". This can (quite reasonably) be
interpreted as that whenever a CA finds out that any CA fails to
comply with any requirement of the policy, this failure to comply must
be promptly reported to Mozilla.

This is of course not applied this way, but this is quite the
reasonable requirement. Only for the requirements after that the
requirements are becoming more unreasonable for CAs that are not part
of the incident.

> It would seem like you might be reaching that conclusion from "When a CA" and 
> "CAs", is that right?

Correct.

>
>>
>> But, the requirements also extend to having to regularly update these
>> incidents, and report these incidents in their audit letter, even if
>> they are not related to that CA.
>
>
> As mentioned above, this seems like an overly broad reading, and I'm 
> wondering if that's the source of confusion here. Understandably, it would 
> make no logical sense to expect a third-party reporter to provide updates for 
> a CA incident, whether that third-party is an individual or another CA.
>
> By the logic being applied here, the ultimate sentence in that same paragraph 
> would imply that, from the moment a CA incident is filed, all CAs in 
> Mozilla's Root Program must stop issuance until the affected CA has resolved 
> the issue, which certainly makes no logical or syntactical sense, or, 
> similarly, that Section 4.2 of the policy obligates CAs to respond on behalf 
> of other CAs.

Yes, this is indeed the overly broad (and impractical) reading that I
suggest to be updated to be more specific and clear about the intent.
Note that I would like to keep the specific requirement for CAs to
report newly found non-compliances by any CA in the Mozilla root store
to Mozilla, even if this non-compliance originates outside the CAs own
trust hierarchy.

For section 2.4, it might also be as easy as replacing 'CAs' with 'the
CA', as that would point to the CA of 'When a CA' instead of all CAs
in the program.


-Matthias
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

[Matthias van de Meent via dev-security-policy]

On Thu, 22 Oct 2020, 20:53 Ben Wilson via dev-security-policy,
 wrote:
> That proposal is to have section 2.4 read as follows:  "If
> being audited to the WebTrust criteria, the Management Assertion letter
> MUST include all known incidents that occurred or were still
> open/unresolved at any time during the audit period."
>
> [...]
>
> Proposed language for section 3.1.4 is:
>
> "11.  all incidents (as defined in section 2.4) that occurred or were still
> open/unresolved at any time during the audit period, or a statement that
> the auditor is unaware of any;"
>
> I look forward to your comments, suggestions and discussions.

The current MRSP do not bind the requirements on the reporting of
incidents to the CA that the incident was filed on, but generally to
CAs.

Section 2.4 has the general requirement for a CA to report any
incident (which is a failure to comply with the MRSP by any CA). So,
if a CA is aware of an incident with another CA which is included in
the Mozilla root store, that must be reported, and I agree with that.

But, the requirements also extend to having to regularly update these
incidents, and report these incidents in their audit letter, even if
they are not related to that CA.

I suggest to update this wording, and clarify these requirements, to
only include incidents that occurred within the CA's certificate
hierarchy, e.g. "11.  all incidents (as defined in section 2.4) that
occurred or were still ..." -> "11.  all incidents (as defined in
section 2.4) _within the CA's trust hierarchy_ that occurred or were
still ...".

I believe the same comment applies to issue #154, and to the
requirements in section 2.4, excluding the requirement to file a
report for incidents when discovered.

-Matthias
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: NAVER: Public Discussion of Root Inclusion Request

[Matthias van de Meent via dev-security-policy]

Hi,

In the CPS v1.4.3 of NAVER, section 4.9.3, I found the following:

> 4.9.3 Procedure for Revocation Request
> The NAVER BUSINESS PLATFORM processes a revocation request as follows:
> [...]
> 4. For requests from third parties, The NAVER BUSINESS PLATFORM personnel 
> begin investigating the request within 24 hours after receipt and decide 
> whether revocation is appropriate based on the following criteria:
>   a. [...], b. [...], c. [...], d. [...]
>   e. Relevant legislation.

The wording here is concerning, as it points to potential legislation
that could disallow NAVER from revoking problematic certificates. Also
of note is that this 'relevant legislation' is not referenced in
section 9.14, Governing Law, nor in 9.16.3, Severability (as required
per BRs 9.16.3).

I also noticed that the "All verification activities" type of event is
not recorded, or at least not documented as such. This is a
requirement from BRs 5.4.1(2)(2).


Regards,

Matthias

On Sat, 10 Oct 2020 at 00:09, Ben Wilson via dev-security-policy
 wrote:
>
> Dear All,
>
> This is to announce the beginning of the public discussion phase of the
> Mozilla root CA inclusion process,
> https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4
> through 9). Mozilla is considering approval of NAVER Business Platform
> Corp.’s request to include the NAVER Global Root Certification Authority as
> a trust anchor with the websites trust bit enabled, as documented in the
> following Bugzilla case:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby initiate a
> 3-week comment period, after which if no concerns are raised, we will close
> the discussion and the request may proceed to the approval phase (Step 10).
>
> *A Summary of Information Gathered and Verified appears here in the CCADB:*
>
> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0261
>
> *NAVER Global Root Certification Authority, *valid from 8/18/2017 to
> 8/18/2037
>
> SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265
>
> https://crt.sh/?id=1321953839
>
> *Root Certificate Download:*
>
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST_file_nm=1c3763b33dbf457d8672371567fd1a12.crt_real_file_nm=naverrca1.crt
>
>
> *CP/CPS:*
>
> Comments 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29)
> through 42 in Bugzilla contain discussion concerning the CPS and revisions
> thereto.
>
> Current CPS is version 1.4.3:
>
> https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf_real_file_nm=NBP%20Certification%20Practice%20Statement%20v1.4.3.pdf
>
> Repository location:  https://certificate.naver.com/bbs/initCrtfcJob.do
>
> *BR Self Assessment* (Excel file) is located here:
>
> https://bugzilla.mozilla.org/attachment.cgi?id=9063955
>
> *Audits:*  Annual audits are performed by Deloitte according to the
> WebTrust Standard and WebTrust Baseline Requirements audit criteria. See
> webtrust.org. The last complete audit period for NAVER was from 1 December
> 2018 to 30 November 2019 and no issues were found. However, the audit
> report was dated 28 April 2020, which was more than three months following
> the end of the audit period. The explanation for the delay in obtaining the
> audit report was as follows, “NBP had received a notification mail on
> updating the audit information from CCADB support in March since the Root
> certificate is only included into Microsoft Root Program. According to
> instructions on the email, I explained that NBP would submit the audit
> update information in April to Microsoft.”  The current audit period ends
> 30 November 2020.
>
> *Mis-Issuances *
>
> According to crt.sh and censys.io, the issuing CA under this root
> (NAVER Secure Certification Authority 1) has issued approximately 80
> certificates. I ran the following query for the issuing CA to identify any
> mis-issuances:
> https://crt.sh/?caid=126361=cablint,zlint,x509lint=2017-08-18,
> and during the course of our review, we identified six test certificates
> with errors. (Such certificates have either been revoked or have expired).
> See:
>
> https://crt.sh/?id=2132664529=cablint,zlint,x509lint
>
> https://crt.sh/?id=2102184572=cablint,zlint,x509lint
>
> https://crt.sh/?id=1478365347=cablint,zlint,x509lint
>
> https://crt.sh/?id=2149282089=cablint,zlint,x509lint
>
> https://crt.sh/?id=2149282369=cablint,zlint,x509lint
>
> https://crt.sh/?id=2282123486=cablint,zlint,x509lint
>
> The explanation provided (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c27) was “Regarding
> CA/B Forum and X.509 lint tests NBP figured out two(2) certificates which
> were not complied with BRs right after issuing them. The domains on SANs of
> the certificates were owned and controlled by NBP. They were immediately
> revoked according to CA procedures. For ZLint tests, the certificate (CN=
> test2-certificate.naver.com) had been issued and became 

BRs 8.7 Self-Audits - externalizable?

[Matthias van de Meent via dev-security-policy]

Hi,

BR section 8.7 (specifically the first paragraph) requires CAs to do a
self-audit at least every 3 months. Is this audit externalizable, e.g.
through hiring an audit firm to perform this 'self-audit', or must
this audit be done internally in the CA?
The wording implies 'internally', but by squinting my eyes it could
also be 'the CA can get anyone to do this audit[0], as long as it
happens'.

Most of the wordings date back to BR v1.0 (s 17.8) and BR v1.3.0,
making it difficult to find the rationales of that specific section.


-Matthias

[0] that is, minus the quarterly DTP audits, as those must be done by
a Validation Specialist (which must be 'employed by the CA', thus with
squinting technically could be a subcontractor?)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Matthias van de Meent via dev-security-policy]

On Fri, 14 Aug 2020, 21:52 Ronald Crane via dev-security-policy, <
dev-security-policy@lists.mozilla.org> wrote:

> It could raise legal issues for a CA to refuse to revoke an obvious
> phishing domain after notice that it is fraudulent, or at least after
> notice that it's actually being used to defraud.
>
> For example, Calif. Penal Code s.530.5 says:
>
> (d)(2) Every person who, with _actual knowledge_ that the personal
> identifying information, as defined in subdivision (b) of Section
> 530.55, of a specific person will be used to commit a violation of
> subsection (a), sells, transfers, _or conveys_ that same personal
> identifying information is guilty of a public offense
>
> (emphasis added). Does a CA "convey[]" "personal identifying
> information" if it leaves unrevoked, after notice, a certificate for a
> domain that is being used to phish bank credentials?
>
> Subdivision (a), in turn, makes it an public offense to "willfully
> obtain[] personal identifying information,  as defined in subdivision
> (b) of Section 530.55, of another person, and use[] that information for
> any unlawful purpose...".  (This would seem to cover actual phishing of
> bank credentials).
>

IANAL, but please note that you quote "personal identifying information [...]
of another person".
AIUI, to trigger clause (d)(2) for the CA, the phishing party would _at the
very least_ need to have obtained a valid certificate (and keypair, to use
this certificate) for a domain that they do not own / are authorized to
control (= PII of another person). The revocation of such certificates is
already covered by the first listing in BR section 4.9.1.1.


This is not legal advice. Consult your favorite lawyer for that.
>
> -R
>

Same here,


-Matthias
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CPS URLs

[Matthias van de Meent via dev-security-policy]

On Mon, 6 Jul 2020 at 19:30, Ryan Sleevi  wrote:
>
> On Mon, Jul 6, 2020 at 1:22 PM Matthias van de Meent via dev-security-policy 
>  wrote:
>>
>> ...
>>
>> 1.) What was the reasoning behind not (also / specifically) allowing
>> an HTTPS url? Was there specific reasoning reasoning?
>
>
> Nope, no specific reasoning. The ambiguity here is whether it's resources 
> dereferenced via an HTTP protocol (which would include HTTP over TLS) or 
> whether it's HTTP schemed resources (which would not). The meaningful 
> distinction was to exclude other forms of scheme/protocols, such as LDAP 
> (inc. LDAPS) and FTP (inc. FTPS)
>
>>
>> 2.) Should this be fixed, or should the batch of certificates with an
>> http `certificatePolicies:policyQualifiers:qualifier:cPSuri` be
>> revoked as misissued?
>
>
> Yeah, this is something that was already flagged as part of the validation WG 
> work to clean up certificate profiles, in that there's other forms of 
> ambiguity here. For example, if one includes an HTTP(S) URL, can they also 
> include one of the undesirable schemes? How many CPS URIs can they include? 
> etc.
>

Great, thanks for the reply, and thanks for the concise information.
Then I shall await such update to the BR.

-Matthias
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CPS URLs

[Matthias van de Meent via dev-security-policy]

Hi,

As per BR v1.7.0, section 7.1.2.3, a Subscriber Certificate MAY
include `certificatePolicies:policyQualifiers:qualifier:cPSuri`, which
must then contain:

> HTTP URL for the Subordinate CA's Certification Practice Statement, Relying 
> Party Agreement or other pointer to online information provided by the CA

(this section has existed as such since at least BR v1.3.0 as such,
and can be traced back all the way to BR v1.0)

I notice that a lot of Subscriber Certificates contain https-based
URLs (e.g. PKIOverheid/KPN, Sectigo, DigiCert), and that other
http-based urls redirect directly to an https-based website (e.g.
LetsEncrypt, GoDaddy).

As I am not part of the CA/B Forum, and could not find open (draft)
ballots in the cabforum/docs repository about updating this section;
I'll ask this:

1.) What was the reasoning behind not (also / specifically) allowing
an HTTPS url? Was there specific reasoning reasoning?
2.) Should this be fixed, or should the batch of certificates with an
http `certificatePolicies:policyQualifiers:qualifier:cPSuri` be
revoked as misissued?
3.) If HTTPS is disallowed for a good reason, then should redirecting
to HTTPS also be disallowed?

Note: In other sections (e.g. 3.2.2.4.18) https is specifically called
out as an allowed protocol.

My personal answer regarding 2. is 'yes, this should be fixed in the
BR', unless there is solid reasoning behind 1.


With regards,

Matthias
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Status of the bugzilla bug list

[Matthias van de Meent via dev-security-policy]

On Tue, 19 May 2020 at 16:22, Ryan Sleevi  wrote:
>
> On Tue, May 19, 2020 at 5:53 AM Matthias van de Meent 
>  wrote:
>>
>> One of the reasons I did this research was to check the track record
>> of CAs with regards to compliance and solving compliance issues. As
>> you might expect, this is quite difficult when the issues are not
>> updated regularly.
>
> I’m not sure I see the connection. For this scenario, it’s actually necessary 
> to read the bugs. We do not use the bug metadata (e.g. opened, last updated, 
> closed date) as part of our own analysis and processing, instead relying on 
> reading the bugs themselves.

I agree that for any one bug, this metadata is not anything to make
decisions over, but when looking over e.g. the last 3 years, you can
start making more informed guesses on the metadata only. E.g. when you
find that a CA has consistently had 4-8 compliance issues open with
only sporadic updates, although this doesn't tell anything about this
CA in and of itself, it does give a (basic) sense of concern. But, as
I've heard, the metadata is even less precise than I'd previously
expected, and thus this road to knowledge is yet to be built.

>> The distinction closed / open is, (although skewed) a decent
>> indication for a CAs compliance track record and their readiness to
>> improve, especially when tracking open issues over time. When the
>> issue state is not linked to the actual solving of the compliance
>> issue, the skewed indication becomes even worse.
>
>
> Thanks. I don’t think we intend for it to be used as such, and so perhaps 
> it’s not surprising that you find the current data unsatisfying. I would 
> disagree that it’s a decent approximation, in part because that’s not 
> something we guarantee, as you can see.
>
> I say this not to disagree that it “could” be useful, but it’s considerably 
> more work and effort, and places the burden back on the Mozilla community to 
> guarantee, for something that isn’t essential for our efforts or necessary 
> for our tasks.
>
> For lack of a better comparison, it is a bit like asking why AIX or BeOS 
> aren’t a tier 1 configuration (
> https://firefox-source-docs.mozilla.org/build/buildsystem/supported-configurations.html
>  ). The answer is because it’s significant burden for limited return.

Thanks, I had not quite considered this part of the equation.

>> The MRSP section 2.4 asks the CA to promptly provide an incident
>> report, and regularly update this report until it is closed. My
>> opinion is that in this section Mozilla also has an implicit duty to
>> the CA - to mark issues as resolved when Mozilla and the CA agree that
>> the compliance issue has been resolved.
>
>
> Thanks. I don’t agree with that implicit duty assertion, and I think the only 
> reason it comes up here is because it’s tied to a use case which is not 
> presently supported.
>
> To use the previous metaphor, this is a bit like saying that if AIX/BeOS, 
> then Mozilla has an implicit duty not to break the build. However, that 
> ignores the notion of support tiers, and what guarantees, if any, are 
> provided.

I believe this is a bad metaphor for what I understand is Mozillas
role in handling Incident Report bugs. MRSP 2.4 specifically calls out
that a Mozilla representative must eventually close the bug (or not?),
and that until that moment (or forever?) the CA must continue
regularly updating this Incident Report. Although I do agree that
Mozilla is not responsible for actively driving the Incident Report
towards closure (that is as I understand it the role of the CA), I do
believe that Mozilla still should take action when the CA is convinced
the Incident Report is complete and can be closed or asks for extra
guidance - be it resolving the bug, be it responding and asking for
missing information. I do believe that a CA has some right to
"reasonable" response times when they believe the incident has been
handled, just like Mozilla asks for "regular updates" on Incident
Reports. Note that I, similar to the MRSP, do not mention what time
frames to expect when talking about "reasonable" or "regular" in this
context.

To continue on your metaphor: I do not expect Tier 1, but maybe more
like somewhere between Tier 2 en Tier 3? A biweekly, monthly or any
regular check for open compliance issues waiting for a reply from
Mozilla would already improve the (observed) situation tremendously.

>> Currently, I cannot see the forest for the trees due to so many issues
>> waiting to be closed, or having their next-update-by -windows long
>> passed, or just plain lack of communication about what is going on.
>> This makes it even more difficult to make informed decisions about
>> those CAs based on compliance track record.
>
>
> To close this out unambiguously: Using purely the bug metadata (i.e. the 
> status, last modified date, etc) will not tell you this story. What you are 
> trying to do is not presently supported.
>
> Would it be nice? Yes, I have no doubt. But that 

Re: Status of the bugzilla bug list

[Matthias van de Meent via dev-security-policy]

Hi Ryan,

On Tue, 19 May 2020 at 00:47, Ryan Sleevi  wrote:
>
> Hi Matthias,
>
> We're aware of this. Could you explain what issue or issues this
> presents to you?

One of the reasons I did this research was to check the track record
of CAs with regards to compliance and solving compliance issues. As
you might expect, this is quite difficult when the issues are not
updated regularly.

The distinction closed / open is, (although skewed) a decent
indication for a CAs compliance track record and their readiness to
improve, especially when tracking open issues over time. When the
issue state is not linked to the actual solving of the compliance
issue, the skewed indication becomes even worse.

> Understanding that different projects can and do use different
> workflows to address their needs, it's not immediately clear to me
> what impact, if any, this might have for you, and it's unclear why the
> distinction between an open bug and a closed bug should be something
> you're concerned about.

The MRSP section 2.4 asks the CA to promptly provide an incident
report, and regularly update this report until it is closed. My
opinion is that in this section Mozilla also has an implicit duty to
the CA - to mark issues as resolved when Mozilla and the CA agree that
the compliance issue has been resolved.

Concerns start to appear when both the CA and Mozilla do not adhere to
the policy that they agreed to, be it explicit (the CA) or implicit
(Mozilla), as all I see is a slippery slope. Although I know there is
no clear timeframe asked for in the MRSP, I do want to ask the related
parties to at least improve upon the current 4w+ timescale, and/or add
realistic next update dates to their compliance issues.

> Understanding what problem(s) you're trying to solve seems more
> productive/useful way to get them addressed. What difference does the
> distinction make for you?

I expect that an open issue is open-ended, has missing information or
has incomplete tasks and thus tells an incomplete story, and that a
closed issue provides an understanding of what the compliance issue
was, and how it was solved. When this open/closed distinction becomes
less clear due to the not closing of issues, it takes longer to
provide an indication that the issue has been solved, and any lessons
learned take longer to propagate to other interested parties (as I see
it).

Currently, I cannot see the forest for the trees due to so many issues
waiting to be closed, or having their next-update-by -windows long
passed, or just plain lack of communication about what is going on.
This makes it even more difficult to make informed decisions about
those CAs based on compliance track record.


With regards,

Matthias
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Status of the bugzilla bug list

[Matthias van de Meent via dev-security-policy]

Hi Jeremy,

Thanks for responding,

On Mon, 18 May 2020 at 21:58, Jeremy Rowley via dev-security-policy
 wrote:
>
> There are others in this same group of pending Mozilla closure:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1496616
> https://bugzilla.mozilla.org/show_bug.cgi?id=1463975
> https://bugzilla.mozilla.org/show_bug.cgi?id=1532559
> https://bugzilla.mozilla.org/show_bug.cgi?id=1502957 (Waiting on Wayne)
>
> -Original Message-
> From: dev-security-policy  On 
> Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Monday, May 18, 2020 1:52 PM
> To: Mozilla 
> Subject: RE: Status of the bugzilla bug list
>
> I think your list of 23 is wrong. For example, bug 1550645 is just waiting 
> for Mozilla closure. It looks like 1605804 is in the same boat.

I believe my list is correct. As I said, the specific list contains
issues that ( " have not been touched for >4 weeks" AND ( "of which it
is unclear why they're still open" OR "of which it is unclear what
they're waiting for" ) ). The list is provided as a guidance, not an
authorative list (that should be the base dashboard). CAs should of
course decide for themselves which issues should be updated & checked.

Further, a comment requesting the closure of the issue is in my
opinion not enough to remove it from this list; When an issue can be
closed, it should have been closed already (there's been >4 weeks for
that without action on Mozilla's part). If an issue is still after
those 4 weeks, then either Mozilla was lax in its closing of issues,
or there is an uncommunicated need for missing information from
Mozilla. This is why they are also included in the list.

This is also why I explicitly called for Mozilla to also check the
issues - a part of the set is "closable" according to the CA, but no
action taken by Mozilla.


With regards,

Matthias
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Status of the bugzilla bug list

[Matthias van de Meent via dev-security-policy]

All,

I have looked at the list of open bugs in the CA compliance dashboard
[0], and I was unpleasantly suprised. There's a total of 75 open
issues at the moment of writing, of which 31 have not seen an update
in 4 weeks, and of which again 23 [1] are not waiting for a planned
future CA or Mozilla action; 30% of the open issues, spread over 14
CAs. (These 23 include issues that end with actions like "A: We will
do this" and "B: We will do that at 'date-long-gone'" when there is no
indication the action has been taken, and no update since.)

Of those 23, 17 have not seen interactions for over 2 months. (!)

The MRSP (v2.7) requires regular updates for incident reports until
the bug is marked as resolved. This means that a CA MUST actively keep
track of the issue, even though this is not always understood by CAs
[2]. I can understand that it is not always clear what information is
still needed to close a bug, but please ask for this information on
the issue when this is not known, so that there are no 'zombie'
tickets.

To remedy the issue of 'many long-standing open CA-Compliance issues
with unclear state', I would like - as a concerned individual and end
user of the root store - to ask the relevant CAs and Mozilla to check
their issues in the ca-compliance board [0], check whether the issues
are 'solved' or what information they need, and update the relevant
issues with the updated information or ask for said missing
information, so that there is a clear understanding which issues are
resolved and which issues need more information / actions by some
party in the issue. As stated before, this process is not always clear
to all CAs [2], and in my experience explicit communication helps a
lot in checking what is needed to solve an issue.


Kind regards,

Matthias van de Meent


[0] 
https://bugzilla.mozilla.org/buglist.cgi?product=NSS=CA%20Certificate%20Compliance_status=__open__
[1] 
https://bugzilla.mozilla.org/buglist.cgi?product=NSS=CA%20Certificate%20Compliance_id=1593776%2C1605804%2C1623356%2C1550645%2C1625767%2C1502957%2C1620561%2C1575022%2C1590810%2C1578505%2C1463975%2C1496616%2C1614448%2C1559765%2C1606380%2C1532559%2C1599916%2C1551372%2C1610767%2C1575530%2C1597950%2C1597947%2C1597948_id_type=anyexact_id=15253621_format=advanced
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1613409
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate OU= fields with missing O= field

[Matthias van de Meent via dev-security-policy]

Hi,

I was notified that the attachments were lost in transmission, so here
are the links:

cert_no_dcv: https://drive.google.com/open?id=1s43AaW5lCkSzbr-If6l2F_gwLkwDVy6w
cert_by_issuer_no_dcv:
https://drive.google.com/open?id=1-er8R2CfcG8CRK4I3KUXnv8PDgGQKc1Y
cert_by_issuer_name_no_dcv:
https://drive.google.com/open?id=1DHwpEwU0qP1FiJx6Wb6L-kMQEIp3atKX

-Matthias

On Fri, 1 Nov 2019 at 11:08, Matthias van de Meent
 wrote:
>
> Hi,
>
> I recently noticed that a lot of leaf certificates [0] have
> organizationalUnitName specified without other organizational
> information such as organizationName. Many times this field is used
> for branding purposes, e.g. "issued through "
> or "SomeBrand SSL".
>
> BR v1.6.6 § 7.1.4.2.2i has guidance on usage of the OU field: "The CA
> SHALL implement a process that prevents an OU attribute from including
> a name, DBA, tradename, trademark, address, location, or other text
> that refers to a specific natural person or Legal Entity unless the CA
> has verified this information in accordance with Section 3.2 and the
> Certificate also contains subject:organizationName, ,
> subject:givenName, subject:surname, subject:localityName, and
> subject:countryName attributes, also verified in accordance with
> Section 3.2.2.1."
>
> As the organizationName and other related attributes are not set in
> many of those certificates, even though e.g. "COMODO SSL Unified
> Communications" is a very strong reference to Sectigo's ssl branding &
> business, I believe the referenced certificate is not issued in line
> with the BR.
>
> Is the above interpretation of BR section 7.1.4.2.2i correct?
>
> - Matthias
>
> [0] please find attached 3 files which contain a query on the crt.sh
> database, with their results ( queried 2019-10-30T10:00:00Z and
> T12:00:00Z )
> The queries count certificate IDs in the range 189000 ...
> 19 (10M possible certificate IDs), and are filtering
> certificates which have an organizationalUnitName <> 'Domain Control
> Validated', but not the organizationName field:
> - cert_no_dcv: Total count count of the filtered certificate_ids
> - cert_by_issuer_no_dcv: Counted, grouped by issuer ID. This can
> contain duplicate counts, but only due to multiple issuer_ca_ids per
> certificate, which should not exist.
> - cert_by_issuer_name_no_dcv: Counted, grouped by issuer &
> organizationalUnitName: Certificates may be counted twice here due to
> multiple OU entries for one certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Certificate OU= fields with missing O= field

[Matthias van de Meent via dev-security-policy]

Hi,

I recently noticed that a lot of leaf certificates [0] have
organizationalUnitName specified without other organizational
information such as organizationName. Many times this field is used
for branding purposes, e.g. "issued through "
or "SomeBrand SSL".

BR v1.6.6 § 7.1.4.2.2i has guidance on usage of the OU field: "The CA
SHALL implement a process that prevents an OU attribute from including
a name, DBA, tradename, trademark, address, location, or other text
that refers to a specific natural person or Legal Entity unless the CA
has verified this information in accordance with Section 3.2 and the
Certificate also contains subject:organizationName, ,
subject:givenName, subject:surname, subject:localityName, and
subject:countryName attributes, also verified in accordance with
Section 3.2.2.1."

As the organizationName and other related attributes are not set in
many of those certificates, even though e.g. "COMODO SSL Unified
Communications" is a very strong reference to Sectigo's ssl branding &
business, I believe the referenced certificate is not issued in line
with the BR.

Is the above interpretation of BR section 7.1.4.2.2i correct?

- Matthias

[0] please find attached 3 files which contain a query on the crt.sh
database, with their results ( queried 2019-10-30T10:00:00Z and
T12:00:00Z )
The queries count certificate IDs in the range 189000 ...
19 (10M possible certificate IDs), and are filtering
certificates which have an organizationalUnitName <> 'Domain Control
Validated', but not the organizationName field:
- cert_no_dcv: Total count count of the filtered certificate_ids
- cert_by_issuer_no_dcv: Counted, grouped by issuer ID. This can
contain duplicate counts, but only due to multiple issuer_ca_ids per
certificate, which should not exist.
- cert_by_issuer_name_no_dcv: Counted, grouped by issuer &
organizationalUnitName: Certificates may be counted twice here due to
multiple OU entries for one certificate.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CPS publications under MRSP section 3.3

[Matthias van de Meent via dev-security-policy]

I noticed that the MRSP section 3.3 states that CPs and CPSes must be
made available to Mozilla under a CC-BY -compatible licence, or are
considered as licenced under CC-BY-SA v4 to Mozilla and the public
when this action has not been taken (3.3 requirement 3).
1.) Does Mozilla re-publish the latest disclosed CPs and CPSes in a
central repository? Or, is there a place I can find these documents
other than the certificate issuer's website?

This same section 3.3 also reads that a change in the CPS must be
added to a changelog via a dated changelog entry.
2.) Is there a guideline on where to find such changelog? The BR does
not seem to have any guidance on this, and "... CAs MUST indicate that
this has happened by incrementing the version number and adding a
dated changelog entry, ..." is the only mention of such changelog.

Question 1 arose when I compared the Sectigo CPS with that of
LetsEncrypt: Sectigo has an 'all rights reserved' copyright notice on
their latest CPS 5.1 [^2], while LetsEncrypt publicly licences it
under the CC-BY v4 [^3]

As an example interpretation on how my question 2 arose; Sectigo has
an archive of CPSes[^4], but these CPSes not seem to have dated
changelog entry, not in the archive list, nor in the CPS itself (there
is no changelog in the CPS), but do have an 'effective from' date.
LetsEncrypt hosts its CPS repository with versions and dates[^5], and
has a datestamped changelog in the CPS[^6]

- Matthias van de Meent


[^1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#33-cps-and-cpses
[^2] https://sectigo.com/uploads/audio/Sectigo-CPS-v5.1.pdf
[^3] https://letsencrypt.org/documents/isrg-cps-v2.5/#1-1-overview
[^4] https://sectigo.com/certificate-practice-statement-archive
[^5] https://letsencrypt.org/repository/#isrg-certification-practice-statement
[^6] 
https://letsencrypt.org/documents/isrg-cps-v2.5/#1-2-document-name-and-identification
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA policy - ComodoCA or Sectigo?

[Matthias van de Meent via dev-security-policy]

On Tue, 5 Feb 2019 at 16:58, Ryan Sleevi  wrote:
>
> On Tue, Feb 5, 2019 at 6:37 AM Matthias van de Meent 
>  wrote:
>>
>> I agree that sectigo hosts a CPS which meets the requirements for them
>> to issue a certificate for the website. The issue is different here,
>> though.
>>
>> The apparent signee (ComodoCA/Sectigo) has issued their CPS here
>> (https://sectigo.com/legal , https://www.comodoca.com/en-us/legal/ ),
>> latest version both being 4.2, which mentions (in section 7.1.1
>> ) that the certificates
>> will be issued according based on the CPS, Appendix C, which only
>> includes 'O=Comodo Limited'-, 'O=Comodo CA Limited'- and 'O=The
>> USERTRUST Network'-issuer certificates.
>>
>> As the signee of my certificate is not included in any way or form in
>> the CPS of neither ComodoCA nor Sectigo, this would _not_ qualify as a
>> certificate signed according to ComodoCAs nor Sectigos CPS (using a
>> strict reading), and as such this would be an indication of a rogue
>> intermediate certificate authority (if that is the correct term).
>>
>> Please advise
>
>
> Thanks for clarifying. Note that Sectigo is the rebranded name of Comodo CA ( 
> https://groups.google.com/d/msg/mozilla.dev.security.policy/Feh5Xk95mtM/JzINdTT7AwAJ
>  ), as the same entity.
>
> I want to make sure I follow your point: Your new remark is that there's 
> nothing amiss with CAA, but you're concerned that Sectigo's CPS does not 
> enumerate all of the intermediates they use to issue, by virtue of not 
> enumerating their subject names within Appendix C, which is cross-referenced 
> by Section 7.1. Is that correct?

That is correct. The CPS enumerate subject names as were it a
conclusive list, in multiple sections (1.4.1, Appendix C and Appendix
D - which is not mentioned throughout the CPS). Apparently this is not
the case, but a conclusive list can only be obtained using certificate
transparency logs and certificate authority repositories. Then there
is still no information about what policies are applied to said
certificates, as the table in 1.4.1 does not include said subject
names.

> CAs are not presently required to disclose those profiles in that detail, but 
> it sounds as if the issue is that Sectigo did not update the CP/CPS following 
> the rebrand. Does that match your understanding of the issue?

That is indeed my understanding.

I've now read that there will be a post-rebrand CPS, so I hope that
this gap in documentation will be resolved soon.

In the meantime, does this qualify as a nonconformance according to
point 7.1.4 in the mozilla certificate policy -- a Certificate Policy
and Certification Practice Statement (or links to a CP and CPS) or
equivalent disclosure document(s) for the CA or CAs in question --?
Using a strict reading, the CPS linked to in the issued certificate
does not cover the certificate (in a strict reading) by not having
CP/CPS information about the CA in question.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA policy - ComodoCA or Sectigo?

[Matthias van de Meent via dev-security-policy]

On Tue, 5 Feb 2019 at 18:05, Robin Alden  wrote:
>
> Wayne, Mattias,
> We have a post-rebrand CPS which is almost ready to publish and has
> a new Certificate Profiles section.

Thanks for the heads-up, is there a projected timeframe in which this
new CPS will be available?

> To the OP's first question, we continue to accept (amongst others)
> comodo.com and comodoca.com as Issuer Domain Names in CAA records that
> authorize us to issue.
>
> RFC6844 says
>  ".. authorizes the holder of the domain nameName> or a party acting under the explicit authority of the holder
>   of that domain name to issue certificates for the domain in which
>   the property is published."
> We are the holder of comodoca.com.  We have explicit authority to use
> comodo.com for this purpose.
>
> We have always disclosed updates to our CAA domains to the CCADB promptly.

As stated earlier in the thread, the main problem is not per se the
CAA domain validation, but about the issuer of the certificates
created after CAA validation, as there was to my knowledge no public
CP/CPS for the intermediates used for the certificate, which raised
red flags in our internal certificate validation process.

> Regards
> Robin Alden
> Sectigo Limited

Regards,

Matthias van de Meent
Cofano Software Solutions (nl)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA policy - ComodoCA or Sectigo?

[Matthias van de Meent via dev-security-policy]

On Mon, 4 Feb 2019 at 18:06, Ryan Sleevi  wrote:
>
> On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via dev-security-policy 
>  wrote:
>>
>> Hi,
>>
>> Today we've bought a wildcard certificate [0] for our cofano.io domain
>> from Sectigo (previously ComodoCA) via a reseller. Our CAA policy
>> describes that only "comodoca.com" can issue wildcards. The
>> certificate has been issued and signed by Sectigo's 'new' intermediate
>> and root [1] [2].
>>
>> My question is the following: Was Sectigo allowed to sign the
>> certificate using their Sectigo (not ComodoCA) keys, while my CAA
>> record specifies 'issuewild "comodoca.com"'?
>
>
> Yes
>
>>
>> I.E. How should a CA name
>> change be reflected in ( CAA ) conformance? Especially since the
>> Sectigo CPS [3] still only specifies Comodo as their issuer name,
>> which conflicts with the CN/O of the signing certificate [1].
>
>
> There's zero requirement about any such mapping.
>
> The Baseline Requirements, Section 2.2, requires that CAs disclose their 
> policies and respected domains for their CAA policy.
>
> Section 3.2.2.8 places more requirements, largely around the 
> processing/validation model. To the question of domain names is not touched.
>
> Thus, a CA can disclose in their CP/CPS many domains, including those of 
> affiliated or non-affiliated CAs. Provided that this is disclosed in their 
> CP/CPS, and their exception process is clearly documented for domains not in 
> that enumerated list, then they're complying.
>
> Sectigo's CP/CPS discloses that they'll issue for comodoca.com (4.2 of their 
> CPS - https://sectigo.com/uploads/files/Comodo-CA-CPS-4-2.pdf ; section 
> 4.2.4), therefore they've met the requirements.

I agree that sectigo hosts a CPS which meets the requirements for them
to issue a certificate for the website. The issue is different here,
though.

The apparent signee (ComodoCA/Sectigo) has issued their CPS here
(https://sectigo.com/legal , https://www.comodoca.com/en-us/legal/ ),
latest version both being 4.2, which mentions (in section 7.1.1
) that the certificates
will be issued according based on the CPS, Appendix C, which only
includes 'O=Comodo Limited'-, 'O=Comodo CA Limited'- and 'O=The
USERTRUST Network'-issuer certificates.

As the signee of my certificate is not included in any way or form in
the CPS of neither ComodoCA nor Sectigo, this would _not_ qualify as a
certificate signed according to ComodoCAs nor Sectigos CPS (using a
strict reading), and as such this would be an indication of a rogue
intermediate certificate authority (if that is the correct term).

Please advise
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CAA policy - ComodoCA or Sectigo?

[Matthias van de Meent via dev-security-policy]

Hi,

Today we've bought a wildcard certificate [0] for our cofano.io domain
from Sectigo (previously ComodoCA) via a reseller. Our CAA policy
describes that only "comodoca.com" can issue wildcards. The
certificate has been issued and signed by Sectigo's 'new' intermediate
and root [1] [2].

My question is the following: Was Sectigo allowed to sign the
certificate using their Sectigo (not ComodoCA) keys, while my CAA
record specifies 'issuewild "comodoca.com"'? I.E. How should a CA name
change be reflected in ( CAA ) conformance? Especially since the
Sectigo CPS [3] still only specifies Comodo as their issuer name,
which conflicts with the CN/O of the signing certificate [1].

Thanks in advance,

Matthias van de Meent

PS. If this is not the correct location for such questions, then
please advise on where to ask instead. My basic knowledge is just that
- basic - and only got me so far. I have searched the archives of this
mailing list for 'CA name change' and 'Sectigo', which both resulted
in no relevant results for this question.

[0] https://crt.sh/?id=1169278151
[1] https://crt.sh/?caid=105493
[2] https://crt.sh/?caid=1167
[3] https://sectigo.com/legal
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy