Symantec: Next Steps

[Gervase Markham]

Thank you again to Andrew Ayer for the original report.

As the community will have seen, these were the tip of an iceberg of
reasonably large proportions. While it's true that we are still waiting
for Symantec to provide information about e.g. how many certificates
have been re-validated and how many revoked, I think there is now enough
clarity for us to start a discussion about next steps. We need to decide:

a) whether what has been revealed should lead to any changes in
Mozilla's Root Store Policy;

b) whether the failures of Symantec and those to whom they had delegated
signing authority are sufficient to warrant sanction and, if so, what.

Policy Change
-------------

Here are some proposals for policy change. Please do comment on these or
suggest others.

Even if we wanted to revoke all of the certs from CrossCert or some
other Symantec RA, that would be effectively technically impossible,
because they are not marked in such a way as to make them identifiable.

Additionally, the audit situation for these RAs, in terms of timeliness,
comprehensiveness and so on, was pretty terrible and Symantec did not
notice.

Policy Proposal 1: require all CAs to arrange it so that certs validated
by an RA are issued from one or more intermediates dedicated solely to
that RA, with such intermediates clearly labelled with the name of the
RA in the Subject.

If we enact Policy Proposal 1, that allows RAs to be cut off, and also
provides a natural point for the CP/CPS and audits of the RA to be
monitored in the CCADB, because they would be attached by the CA to the
issuing intermediate for that RA.

Symantec's oversight of their RAs was clearly inadequate; various forms
of misissuance were not detected.

Policy Proposal 2: something like, require all CAs to make it so that
any internal tests or audits of certificate quality cover RA-issued
certificates as well as their own.

(Not sure how one could police this.)

One Symantec RA, Certsuperior, had a dreadful audit:
https://bug1334377.bmoattachments.org/attachment.cgi?id=8831930

Symantec required the issues to be fixed and a 90-day action plan was
executed to fix them. However, no certificates issued during the period
of suspect operations were checked to see if the poor practice had
caused misissuance.

Policy Proposal 3: All qualified audits must be disclosed to Mozilla,
even if the intent is remediation and re-audit.

The trouble with this would be, I suspect, that the day before the audit
is due to end the CA can, seeing the writing on the wall, send the
auditor away instead of letting them complete their work. So a bad audit
is never finished. Or are there professional ethics rules about that?

It's difficult to write a policy about what Symantec should have done
when faced with such a litany of failure; I would have thrown
Certsuperior overboard immediately if I were them and had read that
audit. At the very least, all certificates issued while it was true that
e.g.:

* There as no legible CPS;
* inadequately-trained personnel were doing issuance;
* the network was an insecure mess; and
* non-trusted staff had access to issuance

should have been fully re-validated. How can we write something to cover
this?

Policy Proposal 4: When a qualified audit calls the quality of domain
validation into question, all certificates affected by the audit finding
must have their domains revalidated after the problem is remedied.

But even that doesn't really cover it. If their validation practices
were theoretically fine but their network was an insecure mess, anyone
could have got in and done anything.

Perhaps we just need to require audit disclosure and say that if Mozilla
ever comes across an audit like that, we'll use the fact that the RA has
their own intermediate to just cut them off.

Failures
--------

As noted by module peer Ryan Sleevi, this is not the first time Symantec
has had difficulties with misissued "test" certificates. It is
disappointing that investigations related to the last incident did not
turn up the problems which have now been discovered. Various forms of
investigation and remediation were not, apparently, applied to
Symantec's RA network in the same way they were supposedly applied at
Symantec.

It seems to me that Symantec's claim is of lack of knowledge - that they
contracted and trained CrossCert to do the right things, and the
auditors said that they were, and they had no evidence that they were
not, and so they assumed everything was fine. The question is whether
that lack of knowledge amounts to negligence.

Comments on this topic, with careful justification, are invited.

[The alleged audit failures, as opposed to alleged failures by Symantec,
will be discussed in a separate process.]

Gerv

[Ryan Sleevi]

On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Policy Proposal 1: require all CAs to arrange it so that certs validated
> by an RA are issued from one or more intermediates dedicated solely to
> that RA, with such intermediates clearly labelled with the name of the
> RA in the Subject.
>
> If we enact Policy Proposal 1, that allows RAs to be cut off, and also
> provides a natural point for the CP/CPS and audits of the RA to be
> monitored in the CCADB, because they would be attached by the CA to the
> issuing intermediate for that RA.
>
> Symantec's oversight of their RAs was clearly inadequate; various forms
> of misissuance were not detected.
>
>

To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
Third Parties from participating in the issuance process? This would be
effectively the same, in as much as the only capability to allow a
third-party to participate in issuance is to operate a subordinate CA.

I think it's procedurally identical to Policy Proposal 1, but it clarifies
more explicitly that RAs are forbidden, and that all participants in the
issuance ecosystem have a specific set of obligations.

>
>
> Failures
> --------
>
> As noted by module peer Ryan Sleevi, this is not the first time Symantec
> has had difficulties with misissued "test" certificates. It is
> disappointing that investigations related to the last incident did not
> turn up the problems which have now been discovered. Various forms of
> investigation and remediation were not, apparently, applied to
> Symantec's RA network in the same way they were supposedly applied at
> Symantec.
>
> It seems to me that Symantec's claim is of lack of knowledge - that they
> contracted and trained CrossCert to do the right things, and the
> auditors said that they were, and they had no evidence that they were
> not, and so they assumed everything was fine. The question is whether
> that lack of knowledge amounts to negligence.
>
> Comments on this topic, with careful justification, are invited.
>
> [The alleged audit failures, as opposed to alleged failures by Symantec,
> will be discussed in a separate process.]
>

Gerv,

have you examined the most recent set of audits? Do you, in your capacity
as CA Certificate policy peer, believe the audits were correct for their
capability and role? Note that several of them were "WebTrust for CAs" -
not "WebTrust for CAs - SSL BR and Network Security". Do you believe that
complies with letter of the Baseline Requirements?

Similarly, do you believe Symantec had an obligation to ensure the proper
licensing status of auditors, prior to accepting such audits?

I think these may represent important questions for Mozilla to determine,
in order to evaluate the fullness of the claim you have summarized, and I
think would equally apply if we were discussing externally-operated
subordinate CAs, correct?

Considering the capability afforded to these RAs - full certificate
issuance through independent domain validation - I'm curious whether you
believe this materially represents a practical distinction from the
issuance of an unconstrained subordinate CA, and how responsible the
issuing CA is for overseeing those operations.

How would Mozilla respond if in every case of "RA", it was replaced with
"Sub-CA"? That seems to be the guiding principle here, since they're
functionally indistinguishable in this case, except the RA brought with it
even greater risk, and lacked sufficient audit controls or technical
mitigations to prevent unauthorized access or ensure adequate logging.

[Nick Lamb]

On Tuesday, 7 March 2017 11:38:09 UTC, Gervase Markham wrote:
> Comments on this topic, with careful justification, are invited.

I am concerned that the specificity of Policy Proposals 1 & 2 risks fighting the last war by focusing so much on the RA role.

To your final question, yes, but I would answer more precisely: The role of CA comes with a duty to properly oversee issuance and in my opinion the lack of knowledge is evidence that (senior management at) the CA was not exercising the necessary oversight. Symantec _should_ have known about this problem because they _should_ have been looking at the work done by their Partner RAs. They didn't know, because they weren't looking, and not looking when you have a duty to look is pretty much textbook negligence.

[Jakob Bohm]

On 07/03/2017 21:37, Ryan Sleevi wrote:
> On Tue, Mar 7, 2017 at 6:37 AM, Gervase Markham via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Policy Proposal 1: require all CAs to arrange it so that certs validated
>> by an RA are issued from one or more intermediates dedicated solely to
>> that RA, with such intermediates clearly labelled with the name of the
>> RA in the Subject.
>>
>> If we enact Policy Proposal 1, that allows RAs to be cut off, and also
>> provides a natural point for the CP/CPS and audits of the RA to be
>> monitored in the CCADB, because they would be attached by the CA to the
>> issuing intermediate for that RA.
>>
>> Symantec's oversight of their RAs was clearly inadequate; various forms
>> of misissuance were not detected.
>>
>>
> To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
> Third Parties from participating in the issuance process? This would be
> effectively the same, in as much as the only capability to allow a
> third-party to participate in issuance is to operate a subordinate CA.
>
> I think it's procedurally identical to Policy Proposal 1, but it clarifies
> more explicitly that RAs are forbidden, and that all participants in the
> issuance ecosystem have a specific set of obligations.
>

The point is NOT to prohibit RAs (which are a good thing if done
right), but to allow revocation of certificates validated by a rogue RA.

The setup under policy 1 would be that the actual CA holds the key and
issuance systems in its own right and under its own security audits,
while the RA only deals with the actual verification steps (such as
checking that Foo Inc is actually incorporated in country X with
official address on Bar Avenue 123 in Baz City according to official
records in the local language).

Policy 1 is also intended for the reseller-RA combination seen in the
Symantec case, where the reseller-RA does other steps that could/should
be done by the CA directly (such as domain validation and suspicious
case double checking).

Policy 1 may still be a problem for the truly local RA scenario where a
large number of similar RAs handle in-person verification steps for a
small geographic area (such as schemes where each city hall handles
checking photo ID of applicants as part of validation at better
than EV level).


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Ryan Sleevi]

On Tue, Mar 7, 2017 at 6:26 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 07/03/2017 21:37, Ryan Sleevi wrote:
>>

>> To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
>> Third Parties from participating in the issuance process? This would be
>> effectively the same, in as much as the only capability to allow a
>> third-party to participate in issuance is to operate a subordinate CA.
>>
>> I think it's procedurally identical to Policy Proposal 1, but it clarifies
>> more explicitly that RAs are forbidden, and that all participants in the
>> issuance ecosystem have a specific set of obligations.
>>
>>

> The point is NOT to prohibit RAs (which are a good thing if done
> right), but to allow revocation of certificates validated by a rogue RA.
>
> The setup under policy 1 would be that the actual CA holds the key and
> issuance systems in its own right and under its own security audits,
> while the RA only deals with the actual verification steps (such as
> checking that Foo Inc is actually incorporated in country X with
> official address on Bar Avenue 123 in Baz City according to official
> records in the local language).
>
> Policy 1 is also intended for the reseller-RA combination seen in the
> Symantec case, where the reseller-RA does other steps that could/should
> be done by the CA directly (such as domain validation and suspicious
> case double checking).
>
> Policy 1 may still be a problem for the truly local RA scenario where a
> large number of similar RAs handle in-person verification steps for a
> small geographic area (such as schemes where each city hall handles
> checking photo ID of applicants as part of validation at better
> than EV level).
>

Jakob,

You basically restated what I said, except still kept the term "RA". Note
that my proposal would not have eliminated the conceptual role you're
describing - this is still facilitated - but it's explicitly called out as
an externally operated subordinate CA, with all the attendant
responsibility and audit criteria. The fact that one or more pieces of
infrastructure is offered by the issuing CA is nothing new, in practice,
and so the ecosystem already deals with (or fails to deal with) this case.

So perhaps it's useful if you can explain why "Delegated Third Party"
(since RA is overloaded to include the pre-validated domain case of an
Enteprise RA, as well as to cover the case where an RA does not perform
domain validation) is a useful concept to support, versus simply treating
it as the well-understood role of externally-operated subordinate CA?

[Jakob Bohm]

I contradicted you in saying that RAs (or DTP as you now want to call
them) were not supposed to be banned by the policy change.

The point of a general-purpose RA (such as the ones that failed in the
Symantec case) is that they are supposed to explicitly perform fewer
functions and be subject to corresponding reduced requirements
(especially if properly setup from the CA end), and are to be audited
accordingly (without duplicated pseudo audit statements about the
nature of the CA hosted infrastructure).

Another type of true RA in the traditional sense is an office that
performs specific limited parts of the validation, with the main CA
doing the rest. For example the RA would check things that cannot be
checked from wherever the CA is located (in person identification,
access to local official records in local language etc.), while the CA
would do all the checks that don't depend on local knowledge, such as
domain checks, BR enforcement etc. These would be subject to even less
audit requirements compared to a subCA, since they perform an even more
limited subset of CA functions.

A type of Delegated Third Party that isn't an RA in the traditional
sense (but may fall under some RA definitions) would be a pre-validated
Enterprise authorized to request certificates for entities that are
fully nested under its validated name spaces (domains, distinguished
names), with the CA reusing (under the 39 month rule) validations of
those name spaces as being under full control of the enterprise. Those
enterprises could in fact be considered as being mere subscribers
rather than delegated third parties.

Except for the proposed new special policy (which serves only to
provide a centralized way for Mozilla to revoke all certificates issued
through a specific RA, and only in cases where the CA is somehow
unwilling to revoke those certificates itself while Mozilla is
unwilling to revoke the CA trust), there is nothing that
should conflate the DTP and CA roles.

[Ryan Sleevi]

On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> I contradicted you in saying that RAs (or DTP as you now want to call
> them) were not supposed to be banned by the policy change.
>

DTPs are the terms from the Baseline Requirements. All responsibilities and
expectations are associated with that term.

As to the statement "were not supposed to be banned by the policy change",
I don't believe Gerv stated that, so it would be useful to understand why
you've stated that. These were a variety of policy proposals - all of which
are meant to change and/or clarify requirements - so I don't think we can
state that simply removing the concept is off the table.

As to the rest of your message, you describe what have historically been
called RAs/DTPs. You have not, however, answered my question - which is
what impact, if any, do you believe would happen if Mozilla considers the
policy I suggested: That is, to require that anything which 'historically'
was considered an RA be treated as an externally operated sub-CA.

I assert that there remains functional equivalence in role and
capabilities, but greater clarity as to expectations and audits. It would
be useful if, for example, you could highlight how such a policy would
create any form of new burden or requirement beyond the desired attributes
- technical capability to revoke and greater assurance of compliance
through public disclosure. Set aside the terminology question - and just
focus on the practical impact, if any.

Again, I assert, there is no negative impact, and any impact is the desired
degree of clarification for which Delegated Third Parties are already
nominally expected to be.

As a practical matter regarding audits, there's no supporting evidence for
the claim that RAs/Delegated Third Parties are allowed to be subject to
less audit requirements than CAs. I'd be curious if you could provide any
evidence in the Baseline Requirements or Mozilla Inclusion Policy to
support this claim, since it would seem to me this is the crux of your
objection.

In short, I'm hoping you can help me understand
* Why you believe it was not intended to 'eliminate' (though the functional
role remains) Delegated Third Parties
* Why you believe that Delegated Third Parties are subject to any less
audit requirement than Externally-Operated Subordinate CAs

You've stated what you believe, but I cannot find evidence to support
either claim.

[Jakob Bohm]

On 08/03/2017 04:21, Ryan Sleevi wrote:
> On Tue, Mar 7, 2017 at 8:08 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>>
>> I contradicted you in saying that RAs (or DTP as you now want to call
>> them) were not supposed to be banned by the policy change.
>>
>
> DTPs are the terms from the Baseline Requirements. All responsibilities and
> expectations are associated with that term.
>
> As to the statement "were not supposed to be banned by the policy change",
> I don't believe Gerv stated that, so it would be useful to understand why
> you've stated that. These were a variety of policy proposals - all of which
> are meant to change and/or clarify requirements - so I don't think we can
> state that simply removing the concept is off the table.
>

I saw nothing in Gervs posting suggesting that banning all kinds of
RA/DTP relationships was the intended effect.

> As to the rest of your message, you describe what have historically been
> called RAs/DTPs. You have not, however, answered my question - which is
> what impact, if any, do you believe would happen if Mozilla considers the
> policy I suggested: That is, to require that anything which 'historically'
> was considered an RA be treated as an externally operated sub-CA.

For the kind of RA that is a combined reseller/control everything
related to issuing (the Symantec case), there would be no significant
change in burden for the RA.

For the kind of RA that only does specific relevant parts of validation
(a "traditional" RA), the suggested policy as written would "simply"
require the CA to set up and maintain one (set of) subCAs for each of
their RAs, while your rephrasing as a ban on RA/DTP relationships would
impose the full cost of a formal WebTrust (etc.) audit on RAs that only
perform a specific limited function that could be audited much cheaper,
provided the CA systems were set up to have little dependency on
certificate specific activities and security at the RAs.

For example, an RA whose sole involvement is to receive a daily list of
company name/idno/address/authorized signatory for pending
applications, go down to the state hall of records and report back
which ones match/do not match official company records (to support EV
certification for that state) would only need auditing of that activity
and the security of the system used to exchange that list and report
with the CAs central validation team. They should not need to pay a
local WebTrust auditor to certify that the many activities done
centrally at the CA (in a different country altogether) meet any
particular requirements, as that should be in scope only for the actual
auditing of the central CA (which should include auditing of the
presence and compliance of the RA audit reports).

For the "Enterprise customer" "DTP" case, I think subjecting each
Enterprise that has a "cheaply issue certs for subnames" account to any
kind of special audit would be as mindbogglingly onerous as requiring
every shop that accepts credit cards via a 3rd party such as Google to
go through and comply with full PCI certification for systems that
never see credit card numbers, only the shopping cart.

For this case, the only thing that needs auditing is that the CA itself
has properly validated that the Enterprise customer has the full
authority to decide and state which of the acceptable subnames are who
they say they are (as per DNS zone delegations for DNSnames, per mail
domain ownership as per e-mail names etc.). In other words the only
thing the Enterprise customer is delegated to validate is those things
for which the Enterprise customer is the ultimate authority anyway.

>
> I assert that there remains functional equivalence in role and
> capabilities, but greater clarity as to expectations and audits. It would
> be useful if, for example, you could highlight how such a policy would
> create any form of new burden or requirement beyond the desired attributes
> - technical capability to revoke and greater assurance of compliance
> through public disclosure. Set aside the terminology question - and just
> focus on the practical impact, if any.
>
> Again, I assert, there is no negative impact, and any impact is the desired
> degree of clarification for which Delegated Third Parties are already
> nominally expected to be.
>
> As a practical matter regarding audits, there's no supporting evidence for
> the claim that RAs/Delegated Third Parties are allowed to be subject to
> less audit requirements than CAs. I'd be curious if you could provide any
> evidence in the Baseline Requirements or Mozilla Inclusion Policy to
> support this claim, since it would seem to me this is the crux of your
> objection.
>
> In short, I'm hoping you can help me understand
> * Why you believe it was not intended to 'eliminate' (though the functional
> role remains) Delegated Third Parties
> * Why you believe that Delegated Third Parties are subject to any less
> audit requirement than Externally-Operated Subordinate CAs
>
> You've stated what you believe, but I cannot find evidence to support
> either claim.
>

[Ryan Sleevi]

On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I saw nothing in Gervs posting suggesting that banning all kinds of
> RA/DTP relationships was the intended effect.

But would you also acknowledge that your originally stated "The point is
NOT to prohibit RAs" is similarly not provided?

I highlight this, because I want to make sure you're not prematurely
dismissing policy suggestions because you disagree.

> As to the rest of your message, you describe what have historically been
>> called RAs/DTPs. You have not, however, answered my question - which is
>> what impact, if any, do you believe would happen if Mozilla considers the
>> policy I suggested: That is, to require that anything which 'historically'
>> was considered an RA be treated as an externally operated sub-CA.
>>
>

> For the kind of RA that is a combined reseller/control everything
> related to issuing (the Symantec case), there would be no significant
> change in burden for the RA.
>
> For the kind of RA that only does specific relevant parts of validation
> (a "traditional" RA), the suggested policy as written would "simply"
> require the CA to set up and maintain one (set of) subCAs for each of
> their RAs, while your rephrasing as a ban on RA/DTP relationships would
> impose the full cost of a formal WebTrust (etc.) audit on RAs that only
> perform a specific limited function that could be audited much cheaper,
> provided the CA systems were set up to have little dependency on
> certificate specific activities and security at the RAs.
>

This misunderstands Policy 1 then, and is perhaps the substance of our
unintentional disagreement.

if a CA sets up and maintains one (set of) sub CAs for each RA, then each
of those subCAs would need to be audited. This is no different than the
existing requirements, within the Baseline Requirements, that each DTP be
audited. I would highlight Section 8 of the Baseline Requirements for you,
and ask that you clarify where, under the existing policies (e.g. ignoring
any policy proposal) you believe there is any provision for allowing a DTP
to be "audited much cheaper".

If you believe such a thing is possible (I would argue incorrectly so, but
hear me out), then what we're effectively saying is that a set of
Principles and Criteria are not examined by the audit, because the
operation and majority of the controls are managed by the "Issuing CA" - at
least, within the world today of CA/RA relationships. If we believe such a
thing is accepted (and again, not supported by the Baseline Requirements,
and to the extent of my interactions with various auditor/practitioners, I
do not believe currently supported by WebTrust), then I hope you can also
see that we can use that self-same logic to conclude that a DTP operating
as a externally operated sub-CA - but one in which the "Issuing CA" handles
the operation and majority of controls for - is effectively the same thing.

Do you agree with that logic? Can you clarify where and why you disagree
with the analysis above?

> For example, an RA whose sole involvement is to receive a daily list of
> company name/idno/address/authorized signatory for pending
> applications, go down to the state hall of records and report back
> which ones match/do not match official company records (to support EV
> certification for that state) would only need auditing of that activity
> and the security of the system used to exchange that list and report
> with the CAs central validation team.

Please provide a citation to the Baseline Requirements or Mozilla policy to
support this statement. I would suggest Section 8.4 provides
counter-evidence to this claim, and as such, because the argument rests on
this claim, needs to be addressed before we might make further progress.

> They should not need to pay a
> local WebTrust auditor to certify that the many activities done
> centrally at the CA (in a different country altogether) meet any
> particular requirements, as that should be in scope only for the actual
> auditing of the central CA (which should include auditing of the
> presence and compliance of the RA audit reports).
>
> For the "Enterprise customer" "DTP" case, I think subjecting each
> Enterprise that has a "cheaply issue certs for subnames" account to any
> kind of special audit would be as mindbogglingly onerous as requiring
> every shop that accepts credit cards via a 3rd party such as Google to
> go through and comply with full PCI certification for systems that
> never see credit card numbers, only the shopping cart.

For this case, the only thing that needs auditing is that the CA itself
> has properly validated that the Enterprise customer has the full
> authority to decide and state which of the acceptable subnames are who
> they say they are (as per DNS zone delegations for DNSnames, per mail
> domain ownership as per e-mail names etc.). In other words the only
> thing the Enterprise customer is delegated to validate is those things
> for which the Enterprise customer is the ultimate authority anyway.

It sounds like you're describing how you think things work. Unfortunately,
that's not consistent with how they're specified to work (again, Section 8)
or how I've proposed for them to work (... again, Section 8).

Worse, I chose the precise term of "Delegated Third Party" to avoid
confusion with the explicitly-called out case within the Baseline
Requirements regarding "Enterprise RA"

I think what you're looking to do is try to base an argument using Section
1.3.2, in which you might have an opportunity to do so. However, what
you've provided is unsupported and unsubstantiated claims, and I don't
think those are useful for the discussion at all, because it's unclear
their basis in reality. I realize that may sound unduly harsh, but I do
believe for such a nuanced policy discussion, it's important to focus on
what is _actually_ required by the current policies. I believe to do less
than that is to do a disservice to the discussion and not to respect
peoples' time.

[Peter Bowen]

On Tue, Mar 7, 2017 at 9:27 PM, Ryan Sleevi via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
]>

>> For example, an RA whose sole involvement is to receive a daily list of
>> company name/idno/address/authorized signatory for pending
>> applications, go down to the state hall of records and report back
>> which ones match/do not match official company records (to support EV
>> certification for that state) would only need auditing of that activity
>> and the security of the system used to exchange that list and report
>> with the CAs central validation team.
>
>
> Please provide a citation to the Baseline Requirements or Mozilla policy to
> support this statement. I would suggest Section 8.4 provides
> counter-evidence to this claim, and as such, because the argument rests on
> this claim, needs to be addressed before we might make further progress.

Section 8.4 says: " If the CA is not using one of the above procedures
and the Delegated Third Party is not an Enterprise RA, then the
CA SHALL obtain an audit report, issued under the auditing standards
that underlie the accepted audit schemes
found in Section 8.1, that provides an opinion whether the Delegated
Third Party’s performance complies with
either the Delegated Third Party’s practice statement or the CA’s
Certificate Policy and/or Certification Practice
Statement."

If the DTP is only performing the functions that Jakob lists, then
they only need an auditor's opinion covering those functions. In fact
there is no way for an auditor to audit functions that don't exist.
For example, consider the WebTrust for CA criteria called "Subordinate
CA Certificate Life Cycle Management". If the only CA in scope for
the audit does not issue Subordinate CA Certificates, then that
criteria is not applicable. Depending on the auditor, it might be
that the CA needs to write in some policy (public or private) "the CA
does not issue Subordinate CA Certificates."

Many auditors vary how much they charge for their work based on the
expected effort required to compete the work. I believe Jakob's point
is that an audit where all the criteria are just "we do not do X" is
very quick -- for example a DTP that does not have a HSM and does not
digitally sign things is going to be a much cheaper audit than one
that does have a HSM and signs things under multi-person control.

[Santhan Raj]

> > For the kind of RA that only does specific relevant parts of validation
> > (a "traditional" RA), the suggested policy as written would "simply"
> > require the CA to set up and maintain one (set of) subCAs for each of
> > their RAs, while your rephrasing as a ban on RA/DTP relationships would
> > impose the full cost of a formal WebTrust (etc.) audit on RAs that only
> > perform a specific limited function that could be audited much cheaper,
> > provided the CA systems were set up to have little dependency on
> > certificate specific activities and security at the RAs.
> >
>
> This misunderstands Policy 1 then, and is perhaps the substance of our
> unintentional disagreement.
>
> if a CA sets up and maintains one (set of) sub CAs for each RA, then each
> of those subCAs would need to be audited. This is no different than the
> existing requirements, within the Baseline Requirements, that each DTP be
> audited. I would highlight Section 8 of the Baseline Requirements for you,
> and ask that you clarify where, under the existing policies (e.g. ignoring
> any policy proposal) you believe there is any provision for allowing a DTP
> to be "audited much cheaper".

Ryan,

Section 8.4 (cited below), as worded today, does not mandate a DTP to go through an audit. Rather, it requires the CA to perform additional out-of-band checks or perform the domain/IPAddress validation (3.2.2.4 & 3.2.2.5) by itself, when the DTP is not audited as per 8.4 (btw BR incorrectly refers to section 8.1 for audit schemes).

It allows (or doesn't prohibit) the DTP to perform other validation checks in 3.2.2 (while the CA performs 3.2.2.4/5) without going through an WebTrust/ETSI audit, and a CA may choose to perform an internal audit of the DTP's process vs forcing them through a WebTrust/ETSI audit.

There are other checks the CA must perform, but as far as I can tell there isn't any requirement that states a "DTP MUST go through an audit" in the BRs.

"If a Delegated Third Party is not currently audited in accordance with Section 8 and is not an Enterprise RA, then prior to certificate issuance the CA SHALL ensure that the domain control validation process required under Section 3.2.2.4 or IP address verification under 3.2.2.5 has been properly performed by the Delegated Third Party by either (1) using an out-of-band mechanism involving at least one human who is acting either on behalf of the CA or on behalf of the Delegated Third Party to confirm the authenticity of the certificate request or the information supporting the certificate request or (2) performing the domain control validation process itself.

[Jakob Bohm]

On 08/03/2017 06:27, Ryan Sleevi wrote:
> On Tue, Mar 7, 2017 at 11:23 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> I saw nothing in Gervs posting suggesting that banning all kinds of
>> RA/DTP relationships was the intended effect.
>
>
> But would you also acknowledge that your originally stated "The point is
> NOT to prohibit RAs" is similarly not provided?
>
> I highlight this, because I want to make sure you're not prematurely
> dismissing policy suggestions because you disagree.
>

I am simply going by the wording in Gervs posting not stating what you
stated. I presume that if Gerv wanted to complete eliminate the DTP
concept for Mozilla trusted CAs, then that's what he would have written.

Having not fully studied the exact wording of the BRs, I operate under
the assumption that the longer phrasing "... an audit report, issued

under the auditing standards that underlie the accepted audit schemes

found in Section 8.1 ..." as quoted from section 8.4 in earlier
discussion of the Symantec case was intentionally so phrased to
indicate that the audit of a DTP would not be the same as a full
WebTrust CA audit, but would only cover those aspects of those criteria
which would be applicable to the performance of the particular DTP role.

If that quote is indeed from the relevant part of the BRs, then I
would posit that if the BR authors had wanted all kinds of DTPs to be
subject to a full WebTrust audit, they would not have used this more
complex phrase.

>
>> For example, an RA whose sole involvement is to receive a daily list of
>> company name/idno/address/authorized signatory for pending
>> applications, go down to the state hall of records and report back
>> which ones match/do not match official company records (to support EV
>> certification for that state) would only need auditing of that activity
>> and the security of the system used to exchange that list and report
>> with the CAs central validation team.
>
>
> Please provide a citation to the Baseline Requirements or Mozilla policy to
> support this statement. I would suggest Section 8.4 provides
> counter-evidence to this claim, and as such, because the argument rests on
> this claim, needs to be addressed before we might make further progress.
>

I refer to the earlier quote ostensibly from section 8.4 itself.

> Worse, I chose the precise term of "Delegated Third Party" to avoid
> confusion with the explicitly-called out case within the Baseline
> Requirements regarding "Enterprise RA"

Sorry, I overlooked the existence of a special case for the "Enterprise
RA" scenario. That part can then be eliminated from the discussion.

[Ryan Sleevi]

On Wed, Mar 8, 2017 at 12:57 AM, Peter Bowen via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> If the DTP is only performing the functions that Jakob lists, then
> they only need an auditor's opinion covering those functions. In fact
> there is no way for an auditor to audit functions that don't exist.
> For example, consider the WebTrust for CA criteria called "Subordinate
> CA Certificate Life Cycle Management". If the only CA in scope for
> the audit does not issue Subordinate CA Certificates, then that
> criteria is not applicable. Depending on the auditor, it might be
> that the CA needs to write in some policy (public or private) "the CA
> does not issue Subordinate CA Certificates."
>
> Many auditors vary how much they charge for their work based on the
> expected effort required to compete the work. I believe Jakob's point
> is that an audit where all the criteria are just "we do not do X" is
> very quick -- for example a DTP that does not have a HSM and does not
> digitally sign things is going to be a much cheaper audit than one
> that does have a HSM and signs things under multi-person control.

So I agree with this - namely, that a DTP audit does not include the
Principles and/or Criteria relevant for the operational aspects they don't
control, because the auditor neither forms an opinion about the third-party
operation. I think a good example, to continue with yours, if the issuing
CA handles the HSM, and is already audited as such, then the auditor will
not opine on another auditors work.

So the scope of a DTP audit will be limited to the functions provided by
the DTP.

But the same is true for an externally operated sub-CA, for which the
majority of services are provided for by the "issuing" CA, and the DTP
performs the validation functions for this sub-CA.

This is why I'm suggesting, from an audit scope, they're functionally
equivalent approach, except one avoids the whole complexity of identifying
where or not a DTP is something different-than a sub-CA, since the _intent_
is true in both, which is that 100% of the capabilities related to issuance
are appropriately audited - either by the DTP/sub-CA or by the issuing
CA/managed CA provided

Does this make it clearer the point I was trying to make, which is that
they're functionally equivalent - due to the fact that both DTPs and
sub-CAs have the issue of multi-party audit scopes?

[Ryan Sleevi]

I think we may read this different, Santhan.

Either the issuing CA must themselves verify the information present in the
request - in which case, the DTP acts as an information aggregator,
effectively, and the CA is performing the verification function - or if the
DTPs validation of the information is to be trusted, then they MUST undergo
an audit.

[Ryan Sleevi]

On Wed, Mar 8, 2017 at 1:36 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I am simply going by the wording in Gervs posting not stating what you
> stated. I presume that if Gerv wanted to complete eliminate the DTP
> concept for Mozilla trusted CAs, then that's what he would have written.
>

Jakob,

This is a frustrating excerise, and I hope you can appreciate. You are
again ascribing an intent, one of which you explicitly stated, to Gerv,
without evidence or support. When challenged on this, you acknowledge
support for this conclusion isn't present - but now you're trying to again
suggest the presumption/wording.

Can we at least agree - for the sake of productive discussion - that
there's no explicit statement that removing DTPs is off the table, so that
we can discuss the substance of that, and you can acknowledge that there's
no provided evidence to support your claim that removing DTPs was not
intended? Can you imagine the possibility that Gerv just simply didn't word
it as such?

> Having not fully studied the exact wording of the BRs, I operate under
> the assumption that the longer phrasing "... an audit report, issued
> under the auditing standards that underlie the accepted audit schemes
> found in Section 8.1 ..." as quoted from section 8.4 in earlier
> discussion of the Symantec case was intentionally so phrased to
> indicate that the audit of a DTP would not be the same as a full
> WebTrust CA audit, but would only cover those aspects of those criteria
> which would be applicable to the performance of the particular DTP role.
>


>
> If that quote is indeed from the relevant part of the BRs, then I
> would posit that if the BR authors had wanted all kinds of DTPs to be
> subject to a full WebTrust audit, they would not have used this more
> complex phrase.
>

The BR authors are terribly flawed (I'm one of them, or at least
maintainers), and the wording complexity and confusion is more often
confusing than intentional.

I hope you consider my reply to Peter on this topic, in which I try to
highlight how the point upon which you're stuck on 'full audit', is a
practical matter that, when applied, is indistinguishable from an DTP audit.

I think you can readily agree that the 'intent' is that the fullness of
capabilities relative to causing issuance are desired to be audited.
Namely, whether we're talking a DTP audit or a CA audit, the intent is that
all CA functions outlined in the Baseilne Requirements can have Principles
and/or Criteria attached to / derived from them, and that every party who
performs some role within it is audited according to that role.

If you can agree to that - which is, I think, the point you're trying to
make with DTP audits - then what we have is a scenario where some functions
are performed by Company A, some functions are performed by Company B.
Whether it's a DTP performing 3.2 validation (Company B) or an entity
performing 3.2 validation for an externally operated sub-CA (Company B), I
think we're in violent agreement that we want to ensure that Company B is
audited according to its role.

Before I introduce any more complexity - can you agree to that as the goal?
Then everything else is just semantics that we can hammer out.

[Jakob Bohm]

Yes, I agree they should be functionally equivalent, in the sense that
all aspects of the operation and issuance are validated, and that one
entity is ultimately responsible for the actions of the others.

The distinction I am making is that the entity named as ultimately
responsible ("the CA") needs an audit report that covers all the
requirements with some requirements possibly audited in the form of
auditing the presence of valid audit report from the other entities
involved.

The entities ("DTPs") that are not "the CA" need audit reports covering
only that which is delegated by "the CA" (and for which an audit report
is thus needed as documentation that "the CA" must provide to auditors
and root programs).

In other words where the audit report for "the CA" would contain
statements such as "managing HSM safety: Performed by delegated entity
X, as confirmed by audit report Y", the audit report for the others
entities ("DTPs") can simply condider their non-jobs as explicitly out
of scope for the audit. It is part of the duty for the auditors of
"the CA" and the relying parties/root programs looking at paperwork
presented by "the CA" to check that all the tasks outsourced by "the
CA" are covered as "in scope" by audit reports for the "DTPs" that
those tasks are outsourced to.

It is this distinction between auditors who only check that which is
requested and auditors who checks that all mandatory aspect are audited
by someone, somewhere which I believe would result in a difference in
cost and effort.

[Peter Bowen]

Ah, but it is not true. I had a very enlightening discussion with
representatives from the WebTrust Task Force at the CA/Browser Forum
meeting in Redmond. CAs must be evaluated on all the WebTrust
criteria that are not marked optional in order to get a WebTrust seal
and the same auditor must do the whole audit. So, sub-CA Foo
contracts with Bar to host the HSM for the sub-CA and handle the
issuing functions (and probably the revocation functions) and if Bar
is also a CA, Bar gets audited twice. One time by Bar's auditor at
Bar's cost and then again by Foo's auditor at Foo's cost.

Note that WebTrust for CA criteria 6 says:

"The Certification Authority maintains effective controls to provide
reasonable assurance that Subscriber
information was properly authenticated (for the registration
activities performed by ABC-CA)."

Given this criteria, the auditor does not have to inspect each RA themselves.

Also note that the only optional criteria are:

2.1 Certificate Policy Management (if applicable)
2.3 CP and CPS Consistency (if applicable)
4.8 CA Key Escrow (if applicable)
5.1 CA-Provided Subscriber Key Generation Services (if supported)
5.2 CA-Provided Subscriber Key Storage and Recovery Services (if supported)
5.3 Integrated Circuit Card (ICC) Life Cycle Management (if supported)
6.2 Certificate Renewal (if supported)
6.7 Certificate Suspension (if supported)

The CA Key Lifecycle controls, including storage and usage, are not
optional, so each sub-CA must be audited on them.

> This is why I'm suggesting, from an audit scope, they're functionally
> equivalent approach, except one avoids the whole complexity of identifying
> where or not a DTP is something different-than a sub-CA, since the _intent_
> is true in both, which is that 100% of the capabilities related to issuance
> are appropriately audited - either by the DTP/sub-CA or by the issuing
> CA/managed CA provided
>
> Does this make it clearer the point I was trying to make, which is that
> they're functionally equivalent - due to the fact that both DTPs and sub-CAs
> have the issue of multi-party audit scopes?

I agree that you suggest an approach that is probably functionally
equivalent, but what you describe is not how WebTrust audits work.

Thanks,
Peter

[Ryan Sleevi]

On Wed, Mar 8, 2017 at 8:46 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Yes, I agree they should be functionally equivalent, in the sense that
> all aspects of the operation and issuance are validated, and that one
> entity is ultimately responsible for the actions of the others.
>
> The distinction I am making is that the entity named as ultimately
> responsible ("the CA") needs an audit report that covers all the
> requirements with some requirements possibly audited in the form of
> auditing the presence of valid audit report from the other entities
> involved.
>

Except that, from discussions with a number of WebTrust auditors, there is
an issue accepting such evidence. So the scenario you describe further is
not what actually happens in practice - and this is part of the motivation
for the Policy suggestion I provided, so that theory and practice can align.

For example, an auditor will not necessarily examine the audits of other
parties - this is true whether the other party is, for example, a
datacenter operator (which relates to physical security principles), a
"Cloud HSM" provider (which relates to key security principles), or what
we've identified as a Delegated Third Party.

If the function is not at all performed by the CA, then as Peter has noted,
the auditor will not report on it - and as a consequence, be unable to
produce a seal.
If the function is _partially_ performed by the CA, then the auditor will
report to the extent that function is provided by the CA.

So the disconnect here is your assertion that auditors are examining these
reports - whether they be sub-CA or DTPs. The extent of the reporting an
auditor performs during such an engagement is to report on the controls
relative to the principles - e.g. does the CA have a documented process to
review such audits, does the auditor have an opinion that such controls
provide sufficient evidence to the criteria and principles, and were they,
to the extent for the period in question, performed as such.

So we end up in a situation where such audits are not required to be
disclosed (at present), such audits may not conform to the expected
standards (and the audits Symantec has provided amply demonstrate this),
and for which the auditor of the 'issuing CA' may provide a clean opinion,
because their opinion was scoped to the specific activities of those
provided by Symantec Corporation (notably, in its omission, excluding that
of delegated third parties). This does not seem a desirable outcome,
particularly because it conflicts with Mozilla's many improvements towards
transparency.

Each of the Policy proposals Gerv has mentioned ends up in this scenario of
insufficiently controlling for and disclosing the concerns related to
issuance.

So now we circle back to the provision of delegated third party services by
reforming it such that it's treated as an externally operated sub-CA. As
Peter has noted, the extent of such audits would need to include the full
activities of that sub-CA in some form - you don't get to carve that up. In
practice, I'm suggesting that the "Issuing CA", during their annual audit
cycle, would have all the relevant controls and policies examined for that
sub-CA as part of the audit engagement and scope, and would perform some
form of 'site visit' to examine the set of controls and procedures relative
to the function they provide. This is, I assert, functionally similar to
the site audits a number of auditors already perform with respect to
third-party datacenter operations (fairly common) or more complex cases
such as managed key material (rare, but done).

It has the benefit, however, of aligning the practice of what an audit
opinion covers (e.g. there's no carve-out for the DTP operations), when the
audit is disclosed (publicly), and the technical capability for distinctive
issuance. I further suggest that anything less is to undermine the goal and
intent of Mozilla policy, which is quite reasonable - know who can issue
certs and what their policies are.

[Ryan Sleevi]

Peter, does my recent clarification help align this? I think we are in
violent agreement with respect to sub-CAs that you don't get to "pick and
choose" the principles and criteria, but for the specific case of DTPs and
their capabilities, was trying to describe how it could fit within the
'site visit' examination, due to the inability to rely on / use third-party
audits as evidence for the basis of opinion forming.

[Peter Bowen]

On Wed, Mar 8, 2017 at 6:50 AM, Ryan Sleevi <ry...@sleevi.com> wrote:

>
> On Wed, Mar 8, 2017 at 9:23 AM, Peter Bowen wrote:
>
>> > Does this make it clearer the point I was trying to make, which is that
>> > they're functionally equivalent - due to the fact that both DTPs and
>> > sub-CAs
>> > have the issue of multi-party audit scopes?
>>
>> I agree that you suggest an approach that is probably functionally
>> equivalent, but what you describe is not how WebTrust audits work.
>
>
> Peter, does my recent clarification help align this? I think we are in
> violent agreement with respect to sub-CAs that you don't get to "pick and
> choose" the principles and criteria, but for the specific case of DTPs and
> their capabilities, was trying to describe how it could fit within the 'site
> visit' examination, due to the inability to rely on / use third-party audits
> as evidence for the basis of opinion forming.

By eliminating the DTP option, you will massively raise costs for CAs
that rely upon local translators and information gatherers. I think a
much better proposal would be to require the CA perform the RA
activity contemplated by BR 3.2.2.4 and 3.2.2.5 and restrict DTPs to
Subject Identity Information validation.

Thanks,
Peter

[Gervase Markham]

On 07/03/17 23:26, Nick Lamb wrote:
> I am concerned that the specificity of Policy Proposals 1 & 2 risks
> fighting the last war by focusing so much on the RA role.

I guess that's possible; however, it's clear to me that we need policy
improvements in this area. If you know where the next war will be, do
let us know :-)

Gerv

[Gervase Markham]

On 07/03/17 20:37, Ryan Sleevi wrote:
> To make it simpler, wouldn't be a Policy Proposal be to prohibit Delegated
> Third Parties from participating in the issuance process? This would be
> effectively the same, in as much as the only capability to allow a
> third-party to participate in issuance is to operate a subordinate CA.

Is this the same as banning the concept of DTPs?

I note, reading the BRs, that there's no process for root programs to
get any access to, or validate, the audit documentation for DTPs. That
doesn't sound great. Making them sub-CAs would solve that?

> have you examined the most recent set of audits?

I have glanced over them, but not studied them in depth.

> Do you, in your capacity
> as CA Certificate policy peer, believe the audits were correct for their
> capability and role? Note that several of them were "WebTrust for CAs" -
> not "WebTrust for CAs - SSL BR and Network Security". Do you believe that
> complies with letter of the Baseline Requirements?

That would be a question I would leave to Kathleen, who is the team
expert here.

> Similarly, do you believe Symantec had an obligation to ensure the proper
> licensing status of auditors, prior to accepting such audits?

No. This may surprise you but, for better or worse, the Mozilla
requirements override those of the BRs (see the Audit section of policy
2.4) and those do not require official licensing of auditors.
Historically, this was because we wanted to leave room for CACert. What
they actually say is that they give definitions of a "competent party"
and "independent party", and then say:

"The burden is on the CA to prove that it has met the above
requirements. However the CA may request a preliminary determination
from us regarding the acceptability of the criteria and/or the competent
independent party or parties by which it proposes to meet the
requirements of this policy."

I think a reasonable person might interpret this to mean that they
needed to pick auditors who fulfilled the requirements in our policy,
but don't need to _prove_ it unless asked. And they are not obliged to
seek our determination. And I think that if we did ask Symantec to prove
that the various bits of E&Y met the criteria in the policy at the time,
I think they could probably do that.

Other root programs may differ, of course.

One could argue that, with CACert and its creative approach to cheaper
auditing not really on the horizon any more, we should drop our custom
definitions and just ask for a licensed auditor.

> I think these may represent important questions for Mozilla to determine,
> in order to evaluate the fullness of the claim you have summarized, and I
> think would equally apply if we were discussing externally-operated
> subordinate CAs, correct?

Yes, I would expect externally-operated sub CAs to have the correct
audits from a Mozilla-qualified auditor.

> Considering the capability afforded to these RAs - full certificate
> issuance through independent domain validation - I'm curious whether you
> believe this materially represents a practical distinction from the
> issuance of an unconstrained subordinate CA, and how responsible the
> issuing CA is for overseeing those operations.

If they didn't have control of the private key of their issuing
intermediate(s) (as it seems they did not), then I do think this is a
practical distinction from them being an unconstrained subordinate CA,
in that they would e.g. not be audited for things like key management.

In terms of the power they have, it's close - and, if the overseeing CA
is not watching, basically identical. And there's the rub. As there is a
distinction, then the CA should have been watching. If the CA were
permitted not to watch, there would or should be no distinction in the
BRs. And there is. Make sense?

Gerv

[Ryan Sleevi]

On Wed, Mar 8, 2017 at 10:30 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 07/03/17 20:37, Ryan Sleevi wrote:

> > To make it simpler, wouldn't be a Policy Proposal be to prohibit
> Delegated
> > Third Parties from participating in the issuance process? This would be
> > effectively the same, in as much as the only capability to allow a
> > third-party to participate in issuance is to operate a subordinate CA.
>

> Is this the same as banning the concept of DTPs?
>
> I note, reading the BRs, that there's no process for root programs to
> get any access to, or validate, the audit documentation for DTPs. That
> doesn't sound great. Making them sub-CAs would solve that?
>

That is precisely the goal. We could define a set of process and procedures
specific to DTPs, which is effectively duplicitive with the handling of
subordinate CAs, or we could strive to align the two both conceptually and
materially, since, as you note below, there's a number of similarities in
the risk profile.

The concern with the approach of both DTPs and subCAs is that it's very
easy for nuanced and subtle distinctions to be introduced, and as such, it
seems better to avoid that when possible by aligning on the majority-common
portion.

> > Similarly, do you believe Symantec had an obligation to ensure the proper
> > licensing status of auditors, prior to accepting such audits?
>

> No. This may surprise you but, for better or worse, the Mozilla
> requirements override those of the BRs (see the Audit section of policy
> 2.4)

Note: It does not appear you've updated
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
- do you plan to?

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
still links to it, as does https://wiki.mozilla.org/CA:Overview - so I
suspect there's still a substantial bit of cleanup work to do here ;)

(Plus the bugs introduced in 2.4 that were missed until the 2.4.1
discussion, such as the scope, which isn't present in 2.3)

> and those do not require official licensing of auditors.
> Historically, this was because we wanted to leave room for CACert. What
> they actually say is that they give definitions of a "competent party"
> and "independent party", and then say:
>

I'm surprised by that reading, because Item 3 of that section states

By "competent party" we mean a person or other entity who is authorized to
perform audits according to the stated criteria (e.g., by the organization
responsible for the criteria or by a relevant government agency) or for
whom there is sufficient public information available to determine that the
party is competent to judge the CA’s conformance to the stated criteria.

In the absence of a proper license, such parties are not "authorized to
perform audits according to the stated criteria", so the only question is
whether "there is sufficient public information available to determine that
the party is competent to judge the CA's conformance to the stated
criteria".

I recognize that Item 2 "replaces" the criteria for Section 8.2, but such a
replacement is neither reflected within the audit report produced (when
complying with the BRs) with respect to the issuing CA's oversight of the
DTP - that is, you might reasonably expect a qualification, but for Mozilla
to ignore said qualification, consistent with Item 2 of "Audit
Requirements".

"The burden is on the CA to prove that it has met the above
> requirements. However the CA may request a preliminary determination
> from us regarding the acceptability of the criteria and/or the competent
> independent party or parties by which it proposes to meet the
> requirements of this policy."
>
> I think a reasonable person might interpret this to mean that they
> needed to pick auditors who fulfilled the requirements in our policy,
> but don't need to _prove_ it unless asked. And they are not obliged to
> seek our determination. And I think that if we did ask Symantec to prove
> that the various bits of E&Y met the criteria in the policy at the time,
> I think they could probably do that.
>

I find this an interesting and surprising interpretation, because I long
believed the intent and letter of Mozilla policy is that Mozilla required
such determination in the cases of accepting subordinate material, and the
burden of proof rests with them when presenting such material to Mozilla
during inclusion.

> Yes, I would expect externally-operated sub CAs to have the correct
> audits from a Mozilla-qualified auditor.
>

Just to be clear: Given the definitions above, you believe it's acceptable
for sub-CAs to be issued to parties on the basis of the CA's judgement as
to whether there is "sufficient public information available to determine
that the party is competent to judge the CA's conformance to the stated
criteria", and that so long as they do so, it does not represent any form
of violation of Mozilla Policy, even if the CA makes an error in that
judgement?

I can understand and appreciate its relevance to root inclusion requests -
in which Mozilla is ultimately responsible for making that judgement and
evaluation - but as you've described, you've suggested a scenario where
even if Mozilla disagrees with the CA's evaluation, and even if the CA is
unable to prove to Mozilla's satisfaction that the auditor meets that
qualified definition, because the CA exercised that judgement, it does not
represent a violation of Mozilla's policy?

I'm sure you can see the danger in that interpretation :)

>
> > Considering the capability afforded to these RAs - full certificate
> > issuance through independent domain validation - I'm curious whether you
> > believe this materially represents a practical distinction from the
> > issuance of an unconstrained subordinate CA, and how responsible the
> > issuing CA is for overseeing those operations.
>

> If they didn't have control of the private key of their issuing
> intermediate(s) (as it seems they did not), then I do think this is a
> practical distinction from them being an unconstrained subordinate CA,
> in that they would e.g. not be audited for things like key management.
>

So the extent of your concern is whether sufficient audit logs were
maintained, since key management is simply a subset of ensuring an
appropriate trail related to issuance and services.

I highlight this, because at least one of these DTPs failed to maintain
sufficient audit logs, and Symantec has stated it plans to continue using
this information - information improperly secured, improperly maintained,
and with improper access controls - for the issuance of certificates.

> In terms of the power they have, it's close - and, if the overseeing CA
> is not watching, basically identical. And there's the rub. As there is a
> distinction, then the CA should have been watching. If the CA were
> permitted not to watch, there would or should be no distinction in the
> BRs. And there is. Make sense?
>

Unfortunately, I'm not sure I follow. Would you be able to rephrase?

[Gervase Markham]

On 08/03/17 16:36, Ryan Sleevi wrote:
> That is precisely the goal. We could define a set of process and procedures
> specific to DTPs, which is effectively duplicitive with the handling of
> subordinate CAs, or we could strive to align the two both conceptually and
> materially, since, as you note below, there's a number of similarities in
> the risk profile.
>
> The concern with the approach of both DTPs and subCAs is that it's very
> easy for nuanced and subtle distinctions to be introduced, and as such, it
> seems better to avoid that when possible by aligning on the majority-common
> portion.

That seems to make sense to me. Given that the BRs have the concept of a
DTP, how can we best align the two in practice? Does requiring every RA
to have its own subCA do that?

> Note: It does not appear you've updated
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
> - do you plan to?

https://bugzilla.mozilla.org/show_bug.cgi?id=1343200 .

It is a bit sad that a content push to our website requires the work to
be scheduled in a sprint, but I digress. The fix is now on their master
branch; I don't know how often they push to production. Looking at
https://github.com/mozilla/bedrock/commits/prod , it may be as
infrequently as once a week :-((

> I'm surprised by that reading, because Item 3 of that section states
>
> By "competent party" we mean a person or other entity who is authorized to
> perform audits according to the stated criteria (e.g., by the organization
> responsible for the criteria or by a relevant government agency) or for
> whom there is sufficient public information available to determine that the
> party is competent to judge the CA’s conformance to the stated criteria.
>
> In the absence of a proper license, such parties are not "authorized to
> perform audits according to the stated criteria", so the only question is
> whether "there is sufficient public information available to determine that
> the party is competent to judge the CA's conformance to the stated
> criteria".

Yep, with you so far.

> I recognize that Item 2 "replaces" the criteria for Section 8.2, but such a
> replacement is neither reflected within the audit report produced (when
> complying with the BRs) with respect to the issuing CA's oversight of the
> DTP - that is, you might reasonably expect a qualification, but for Mozilla
> to ignore said qualification, consistent with Item 2 of "Audit
> Requirements".

Can an audit be qualified (in the audit sense) by virtue of the person
_doing_ the audit not being formally qualified (in the other sense!) to
use those criteria? I would expect audit qualifications to relate to the
audit subject, not the auditor.

> "The burden is on the CA to prove that it has met the above
>> requirements. However the CA may request a preliminary determination
>> from us regarding the acceptability of the criteria and/or the competent
>> independent party or parties by which it proposes to meet the
>> requirements of this policy."
>>
>> I think a reasonable person might interpret this to mean that they
>> needed to pick auditors who fulfilled the requirements in our policy,
>> but don't need to _prove_ it unless asked. And they are not obliged to
>> seek our determination. And I think that if we did ask Symantec to prove
>> that the various bits of E&Y met the criteria in the policy at the time,
>> I think they could probably do that.
>
> I find this an interesting and surprising interpretation, because I long
> believed the intent and letter of Mozilla policy is that Mozilla required
> such determination in the cases of accepting subordinate material, and the
> burden of proof rests with them when presenting such material to Mozilla
> during inclusion.

It would, you are right. But these audits were not submitted to us
(until recently) because they did not have to be, and so the question
did not arise.

>> Yes, I would expect externally-operated sub CAs to have the correct
>> audits from a Mozilla-qualified auditor.
>
> Just to be clear: Given the definitions above, you believe it's acceptable
> for sub-CAs to be issued to parties on the basis of the CA's judgement as
> to whether there is "sufficient public information available to determine
> that the party is competent to judge the CA's conformance to the stated
> criteria", and that so long as they do so, it does not represent any form
> of violation of Mozilla Policy, even if the CA makes an error in that
> judgement?

No, because in the case of a sub-CA, we require audits. And when we
receive them, if they were done by unqualified parties, the CA would
need to flag that, and we would make a judgement about that party's
suitability at the time. The issue here arises that, because of the way
things are set up, these RA's audits were not submitted to Mozilla, and
so Symantec didn't have to resolve the Schrodinger's Cat of
(qualified|not qualified and need us to make a judgement).

Having danced enough angels for sufficiently long on the head of this
pin, though, it's clear we should fix this. I propose we switch our
auditor requirements to requiring qualified auditors, and saying that
exceptions can be applied for in writing to Mozilla in advance of the
audit starting, in which case Mozilla will make its own determination as
to the suitability of the suggested party or parties. This would involve
removing bullets 3-6 in the Audit section of 2.4, and rewording bullet 2
to say something like the above.

>> If they didn't have control of the private key of their issuing
>> intermediate(s) (as it seems they did not), then I do think this is a
>> practical distinction from them being an unconstrained subordinate CA,
>> in that they would e.g. not be audited for things like key management.
>
> So the extent of your concern is whether sufficient audit logs were
> maintained, since key management is simply a subset of ensuring an
> appropriate trail related to issuance and services.

Well, and making sure it's in an HSM, and physically secure, and... right?

> I highlight this, because at least one of these DTPs failed to maintain
> sufficient audit logs, and Symantec has stated it plans to continue using
> this information - information improperly secured, improperly maintained,
> and with improper access controls - for the issuance of certificates.

Hmm. Good point.

>> In terms of the power they have, it's close - and, if the overseeing CA
>> is not watching, basically identical. And there's the rub. As there is a
>> distinction, then the CA should have been watching. If the CA were
>> permitted not to watch, there would or should be no distinction in the
>> BRs. And there is. Make sense?
>
> Unfortunately, I'm not sure I follow. Would you be able to rephrase?

An unwatched RA and a sub-CA are effectively equivalent in power. A
watched RA and a sub-CA might not be, if the CA is exercising effective
control and limits on their issuance. There is a distinction in the BRs
between an RA and a sub-CA, with the RA having less onerous
requirements. One could say that the very existence of that distinction
implies that CAs have a duty to carefully watch their RAs.

Gerv

[Ryan Sleevi]

On Thu, Mar 9, 2017 at 6:48 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> That seems to make sense to me. Given that the BRs have the concept of a
> DTP, how can we best align the two in practice? Does requiring every RA
> to have its own subCA do that?
>

(Wearing Google hat only for this statement)
Have you considered having this discussion in the CA/Browser Forum? Google
had planned to discuss this very topic at our upcoming F2F about how to
address this, and would be very interested in collaborating with Mozilla on
this. I mentioned this recently to Kathleen at the WebTrust TF meetings,
but apologies for not mentioning to you as well.

> > I recognize that Item 2 "replaces" the criteria for Section 8.2, but
> such a
> > replacement is neither reflected within the audit report produced (when
> > complying with the BRs) with respect to the issuing CA's oversight of the
> > DTP - that is, you might reasonably expect a qualification, but for
> Mozilla
> > to ignore said qualification, consistent with Item 2 of "Audit
> > Requirements".
>

> Can an audit be qualified (in the audit sense) by virtue of the person
> _doing_ the audit not being formally qualified (in the other sense!) to
> use those criteria? I would expect audit qualifications to relate to the
> audit subject, not the auditor.
>

(Back to non-Google hat)
You've misunderstood. An auditor performing an audit is not going to
"self-qualify" because they aren't licensed. HOWEVER, an Auditor examining
the Principles/Criteria of an Issuing CA is going to examine the controls
of that CA relative to the operation of DTPs and sub-CAs, and those
Principles/Criteria are based on the Baseline Requirements. If the "sub"
auditor is not properly licensed - despite that "sub" auditor meeting the
definition of Mozilla's "replacement" 8.2, then the issuing CA should
reasonably be expected to receive a qualification that their controls are
insufficient for the criteria of the Baseline Requirements (which does not
have the replacement 8.2)

Does that make more sense? In the Sub-CA case, this is "Principle 2: SSL
Service Integrity", Criteria 8.2, and for DTPs, Criteria 8.4

> >> Yes, I would expect externally-operated sub CAs to have the correct
> >> audits from a Mozilla-qualified auditor.
> >
> > Just to be clear: Given the definitions above, you believe it's
> acceptable
> > for sub-CAs to be issued to parties on the basis of the CA's judgement as
> > to whether there is "sufficient public information available to determine
> > that the party is competent to judge the CA's conformance to the stated
> > criteria", and that so long as they do so, it does not represent any form
> > of violation of Mozilla Policy, even if the CA makes an error in that
> > judgement?
>

> No, because in the case of a sub-CA, we require audits. And when we
> receive them, if they were done by unqualified parties, the CA would
> need to flag that, and we would make a judgement about that party's
> suitability at the time. The issue here arises that, because of the way
> things are set up, these RA's audits were not submitted to Mozilla, and
> so Symantec didn't have to resolve the Schrodinger's Cat of
> (qualified|not qualified and need us to make a judgement).
>
> Having danced enough angels for sufficiently long on the head of this
> pin, though, it's clear we should fix this. I propose we switch our
> auditor requirements to requiring qualified auditors, and saying that
> exceptions can be applied for in writing to Mozilla in advance of the
> audit starting, in which case Mozilla will make its own determination as
> to the suitability of the suggested party or parties. This would involve
> removing bullets 3-6 in the Audit section of 2.4, and rewording bullet 2
> to say something like the above.
>

I'm not sure that we can or should so easily dismiss this with a suggestion
that we're dancing on the head of a pin here. I don't understand why you
believe it's relevant the act of "Mozilla requiring disclosure of the
audits". Can you help me understand where, in the policy, that's required?

I highlight this because the question of "qualified or not qualified", for
RAs (which are not disclosed), is one where the CA accepts a liability of
the decision if they do not seek Mozilla's guidance. For the question of
appropriately WebTrust licensed, this has an objective basis for which
compliance with Mozilla can be demonstrated at the time the audit was
accepted. However, if entering in the to the "CA's discretion" side of the
availability of the public information, any CA that fails to obtain
Mozilla's opinion a priori bears the liability and responsibility if they
stuff that judgement up.

I agree that removing the conflicting definition of qualified auditor is
likely a suitable outcome, and a much welcome improvement, but I do think
we owe it to the community to provide a greater degree of clarity then
currently provided by this thread about the expectations related to such
audits, both to the qualifications and the independence aspects.

>
> >> If they didn't have control of the private key of their issuing
> >> intermediate(s) (as it seems they did not), then I do think this is a
> >> practical distinction from them being an unconstrained subordinate CA,
> >> in that they would e.g. not be audited for things like key management.
> >
> > So the extent of your concern is whether sufficient audit logs were
> > maintained, since key management is simply a subset of ensuring an
> > appropriate trail related to issuance and services.
>

> Well, and making sure it's in an HSM, and physically secure, and... right?
>

No. That's a means to an end, not an end in itself.

The only reason you care about the HSM and physical security is because
without the HSM and physical security, you can no longer trust the audit
logs as sufficient, because you don't know who was signing with the key.
But if you equally can't trust the audit logs, then to me, it's no
different than if the key was not in an HSM - you still don't know who was
signing with a key.

I'm trying to separate out the objective from the means of meeting that
objective, and I don't believe the key management aspect is a goal in and
of itself, but rather one that helps achieve a goal.

The difference between a sub-CA and a DTP in this case is that the issuance
of the certificates themselves MAY be identified by the parent-CA, if the
parent-CA is maintaining proper audit logs, but the information related to
the cause of that issuance is dependent on the DTP. If you have reason to
suspect that the parent-CA has not maintained proper audit logs - such as,
for example, having received a qualification on Criteria 3.10 of the
WebTrust for CAs - SSL Baseline Requirements regarding the proper
protection of their audit logs and physical security for the protection of
said logs - such as Symantec has -
https://www.symantec.com/content/en/us/about/media/repository/Symantec-STN-WTCA-2015.pdf
- then the ability to distinguish a DTP and a sub-CA is significantly
diminished.

> An unwatched RA and a sub-CA are effectively equivalent in power. A
> watched RA and a sub-CA might not be, if the CA is exercising effective
> control and limits on their issuance. There is a distinction in the BRs
> between an RA and a sub-CA, with the RA having less onerous
> requirements. One could say that the very existence of that distinction
> implies that CAs have a duty to carefully watch their RAs.

Well, that duty is also spelled out in the BRs and the WebTrust Principles
and Criteria, but yes, I very much agree with that assessment, and that
duty to carefully watch is one that is both logically derived from the
principles and explicitly stated :)

[Steve Medin]

In the case of CrossCert, where we have evidence of failure to properly document their work, we are NOT relying on their previous work and have begun fully revalidating all active certificates. In the cases of the other 3 RAs, our focus is reviewing all of the work previously done to verify that it can, in fact, be relied upon and/or determine where full revalidation, without relying on the prior work of the RA, is warranted, if at all.

[Ryan Sleevi]

On Thu, Mar 9, 2017 at 1:34 PM, Steve Medin via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> In the case of CrossCert, where we have evidence of failure to properly
> document their work, we are NOT relying on their previous work and have
> begun fully revalidating all active certificates. In the cases of the other
> 3 RAs, our focus is reviewing all of the work previously done to verify
> that it can, in fact, be relied upon and/or determine where full
> revalidation, without relying on the prior work of the RA, is warranted, if
> at all.
>

Steve,

While I appreciate your reply, I think it highlights precisely the concern
about whether or not Symantec is qualified and/or should be trusted to make
this determination, given that Symantec is in possession of documented
evidence from one of their other RA partners about a failure to properly
document their work and to ensure the authenticity of what was documented.

Given your reply above, I think it's reasonable for readers to conclude
that Symantec's Compliance Team, despite having been alerted to these
issues on February 8, and having been aware of them for far longer, has
decided that they are not significant. I'm not sure how such a conclusion
is consistent with the information provided, and eagerly await any
explanation Symantec may offer.

Further, you have acknowledged that at least one auditor lacked sufficient
skill and licensing to perform the audit. It is also clear that one or more
of these RA partners was not audited with respect to "WebTrust Principles
and Criteria for Certification Authorities - SSL Baseline with Network
Security", and as such, lacks effective demonstration of adherence to the
security-relevant Principles and Criteria contained therein, only having
produced audits to the effect of "WebTrust Principles and Criteria for
Certification Authorities".

As demonstrated by the historical audits, the issues presented issues span
multiple years, so even remediation plans that may have been effected for
one or more of these delegated third parties, such plans do not
retroactively 'correct' any misissuance or bad data logged in such systems.

Finally, I am uncertain how any of Symantec's proposal is consistent with
its CP/CPS, which incorporates the Baseline Requirements. In particular,
Symantec has now had six weeks, and still has failed to abide by the terms
of Section 4.9.1.1 regarding these 30,000 certificates.

Regardless of the next steps Symantec may take, I think it's reasonable to
suggest that these are all extremely important for members of the community
to carefully contemplate, and all of them rest specifically with actions
and statements made by Symantec since this investigation began, rather than
the RA partners.

[Jeremy Rowley]

Cut:

> An unwatched RA and a sub-CA are effectively equivalent in power. A
> watched RA and a sub-CA might not be, if the CA is exercising
> effective control and limits on their issuance. There is a distinction
> in the BRs between an RA and a sub-CA, with the RA having less onerous
> requirements. One could say that the very existence of that
> distinction implies that CAs have a duty to carefully watch their RAs.

The equivalency of power is not true most of the time. The term RA/DTP
covers a lot of different roles. For example, four commonly used roles are:
1) An entity that does the translation of documents for the CA as defined in
the EV Guidelines
2) An entity that gathers the validation documents and submits them to the
CA for review in the validation process
3) An entity that identifies the subject identity information for a
certificate (for example, in some schools the department may provide the
identity proofing of a student that is getting a certificate)
4) An entity that provides verification of the entire certificate contents.

Although #3 and #4 should perhaps be audited, by applying a broad
requirement you end up capturing a lot more delegated entities than
intended. The broad and diverse role of DTPs in the ecosystem is why the
audit requirements in Section 8.4 were written to only require audits over
those that provide domain validation. Whatever policy is decided, I'm
hoping we can exclude translators and entities that are merely gathering
documentation.

Jeremy

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, March 9, 2017 6:32 AM
To: Gervase Markham <ge...@mozilla.org>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Symantec: Next Steps

On Thu, Mar 9, 2017 at 6:48 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> That seems to make sense to me. Given that the BRs have the concept of
> a DTP, how can we best align the two in practice? Does requiring every
> RA to have its own subCA do that?
>

(Wearing Google hat only for this statement) Have you considered having this
discussion in the CA/Browser Forum? Google had planned to discuss this very
topic at our upcoming F2F about how to address this, and would be very
interested in collaborating with Mozilla on this. I mentioned this recently
to Kathleen at the WebTrust TF meetings, but apologies for not mentioning to
you as well.

> > I recognize that Item 2 "replaces" the criteria for Section 8.2, but
> such a
> > replacement is neither reflected within the audit report produced
> > (when complying with the BRs) with respect to the issuing CA's
> > oversight of the DTP - that is, you might reasonably expect a
> > qualification, but for
> Mozilla
> > to ignore said qualification, consistent with Item 2 of "Audit
> > Requirements".
>

> Can an audit be qualified (in the audit sense) by virtue of the person
> _doing_ the audit not being formally qualified (in the other sense!)
> to use those criteria? I would expect audit qualifications to relate
> to the audit subject, not the auditor.
>

(Back to non-Google hat)
You've misunderstood. An auditor performing an audit is not going to
"self-qualify" because they aren't licensed. HOWEVER, an Auditor examining
the Principles/Criteria of an Issuing CA is going to examine the controls of
that CA relative to the operation of DTPs and sub-CAs, and those
Principles/Criteria are based on the Baseline Requirements. If the "sub"
auditor is not properly licensed - despite that "sub" auditor meeting the
definition of Mozilla's "replacement" 8.2, then the issuing CA should
reasonably be expected to receive a qualification that their controls are
insufficient for the criteria of the Baseline Requirements (which does not
have the replacement 8.2)

Does that make more sense? In the Sub-CA case, this is "Principle 2: SSL
Service Integrity", Criteria 8.2, and for DTPs, Criteria 8.4

> >> Yes, I would expect externally-operated sub CAs to have the correct
> >> audits from a Mozilla-qualified auditor.
> >
> > Just to be clear: Given the definitions above, you believe it's
> acceptable
> > for sub-CAs to be issued to parties on the basis of the CA's
> > judgement as to whether there is "sufficient public information
> > available to determine that the party is competent to judge the CA's
> > conformance to the stated criteria", and that so long as they do so,
> > it does not represent any form of violation of Mozilla Policy, even
> > if the CA makes an error in that judgement?
>

> >> If they didn't have control of the private key of their issuing
> >> intermediate(s) (as it seems they did not), then I do think this is
> >> a practical distinction from them being an unconstrained
> >> subordinate CA, in that they would e.g. not be audited for things like
key management.
> >
> > So the extent of your concern is whether sufficient audit logs were
> > maintained, since key management is simply a subset of ensuring an
> > appropriate trail related to issuance and services.
>

and explicitly stated :) _______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Gervase Markham]

On 09/03/17 13:32, Ryan Sleevi wrote:
> (Wearing Google hat only for this statement)
> Have you considered having this discussion in the CA/Browser Forum? Google
> had planned to discuss this very topic at our upcoming F2F about how to
> address this, and would be very interested in collaborating with Mozilla on
> this. I mentioned this recently to Kathleen at the WebTrust TF meetings,
> but apologies for not mentioning to you as well.

This sounds like a good idea. Do we want to get this added in an open
slot? There may still be time.

> I'm not sure that we can or should so easily dismiss this with a suggestion
> that we're dancing on the head of a pin here.

That's not quite what I'm saying; I'm saying that my position could be
seen as that (making very fine distinctions), and it possibly is.

> I don't understand why you
> believe it's relevant the act of "Mozilla requiring disclosure of the
> audits". Can you help me understand where, in the policy, that's required?

I'm not sure where your text in quotes comes from, and nor can I work
out the referent of "it", so I don't understand this question.

> I agree that removing the conflicting definition of qualified auditor is
> likely a suitable outcome, and a much welcome improvement, but I do think
> we owe it to the community to provide a greater degree of clarity then
> currently provided by this thread about the expectations related to such
> audits, both to the qualifications and the independence aspects.

Surely requiring the auditor to be qualified in all cases will provide
that clarity?

I've filed https://github.com/mozilla/pkipolicy/issues/63 .

Gerv

[Gervase Markham]

On 08/03/17 15:06, Peter Bowen wrote:
> By eliminating the DTP option, you will massively raise costs for CAs
> that rely upon local translators and information gatherers. I think a
> much better proposal would be to require the CA perform the RA
> activity contemplated by BR 3.2.2.4 and 3.2.2.5 and restrict DTPs to
> Subject Identity Information validation.

Let's call that "Policy Proposal 5" :-)

I think that if we did this, it might still make sense to enact Policy
Proposal 1. I believe that would have the side effect of making sure we
get all the audits.

Gerv

[Ryan Sleevi]

On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 09/03/17 13:32, Ryan Sleevi wrote:

> > (Wearing Google hat only for this statement)
> > Have you considered having this discussion in the CA/Browser Forum?
> Google
> > had planned to discuss this very topic at our upcoming F2F about how to
> > address this, and would be very interested in collaborating with Mozilla
> on
> > this. I mentioned this recently to Kathleen at the WebTrust TF meetings,
> > but apologies for not mentioning to you as well.
>

> This sounds like a good idea. Do we want to get this added in an open
> slot? There may still be time.
>

Unconference future discussion. If CAs aren't interested in it, and it
doesn't get discussed, then that seems like a suitable signal to discuss in
the browser policies, doesn't it?

> > I don't understand why you
> > believe it's relevant the act of "Mozilla requiring disclosure of the
> > audits". Can you help me understand where, in the policy, that's
> required?
>

> I'm not sure where your text in quotes comes from, and nor can I work
> out the referent of "it", so I don't understand this question.
>

The quoted text was attempting to summarize the following paragraph from
you:

"""No, because in the case of a sub-CA, we require audits. And when we
receive them, if they were done by unqualified parties, the CA would
need to flag that, and we would make a judgement about that party's
suitability at the time. The issue here arises that, because of the way
things are set up, these RA's audits were not submitted to Mozilla, and
so Symantec didn't have to resolve the Schrodinger's Cat of
(qualified|not qualified and need us to make a judgement)."""

The question here is that it seems you have hinged the
acceptability/unacceptability of the auditor on the basis of whether or not
it was required to be disclosed.

Or, put differently, it sounds as if you suggest the only obligation a CA
has to ensure their DTP auditors are qualified for the task at hand is if,
and only if, Mozilla requests those audits. In the absence of that request,
the CA is allowed to make their own individual determination. Further, it
seems that you are suggesting that if a CA makes that determination, and
it's incorrect, that's not a failure upon the CAs part, because they made
'a decision', and the relevant portions of Mozilla policy only apply to the
'next' audit.

In effect, it makes the question of 'qualified' auditor one which can never
look retrospectively to prevent issues or instill a duty of care, and it
only applies forward thinking, to the 'next' audits. Or, put differently,
it sounds as if you're suggesting that Symantec, having made a
determination of qualified without input from Mozilla, has sufficiently
abided by Mozilla's policy.

I'm not sure that's a consistent read with the goals or policy stated.
Rather, by making that determination without input from Mozilla, Symantec
has instead taken on full liability for that audit. If, as in this case,
evidence appears that suggests the auditor is not qualified, then the root
issue rests with Symantec for not ensuring that the auditor was qualified.
Similarly, all other CAs who are accepting audits from third-parties
(whether DTPs or sub-CAs), and which are not ensuring those meet the
definition of qualified, similarly accept risk of violation. That risk can
be mitigated - for example, showing that the auditor is appropriately
licensed at the time they conducted the audit, rejecting audits that are
clearly problematic - but it's a risk born through exercising the
capability to delegate.

Put one last way (since this is such a thorny issue), I read your reply in
the above quoted text to say "Mozilla requires that the CA make a decision.
But it doesn't have to be a right one, and it doesn't have to use the same
data we would." I'm trying to push back on that, which is every CA has an
obligation to make the Right Decision - they have the tools at their
disposal to do so, but uncertainty or perceived risk can and should only be
mitigated by public consultation before - not after.

[Jeremy Rowley]

We have DTP and RA roles slated as part of the validation WG discussion, but
only as they relate to validation.

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, March 16, 2017 7:16 AM
To: Gervase Markham <ge...@mozilla.org>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Symantec: Next Steps

On Thu, Mar 16, 2017 at 6:01 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 09/03/17 13:32, Ryan Sleevi wrote:

> > (Wearing Google hat only for this statement) Have you considered
> > having this discussion in the CA/Browser Forum?
> Google
> > had planned to discuss this very topic at our upcoming F2F about how
> > to address this, and would be very interested in collaborating with
> > Mozilla
> on
> > this. I mentioned this recently to Kathleen at the WebTrust TF
> > meetings, but apologies for not mentioning to you as well.
>

> This sounds like a good idea. Do we want to get this added in an open
> slot? There may still be time.
>

Unconference future discussion. If CAs aren't interested in it, and it
doesn't get discussed, then that seems like a suitable signal to discuss in
the browser policies, doesn't it?

> > I don't understand why you
> > believe it's relevant the act of "Mozilla requiring disclosure of
> > the audits". Can you help me understand where, in the policy, that's
> required?
>

> I'm not sure where your text in quotes comes from, and nor can I work
> out the referent of "it", so I don't understand this question.
>

The quoted text was attempting to summarize the following paragraph from
you:

"""No, because in the case of a sub-CA, we require audits. And when we
receive them, if they were done by unqualified parties, the CA would need to
flag that, and we would make a judgement about that party's suitability at
the time. The issue here arises that, because of the way things are set up,
these RA's audits were not submitted to Mozilla, and so Symantec didn't have
to resolve the Schrodinger's Cat of (qualified|not qualified and need us to
make a judgement)."""

[Gervase Markham]

On 16/03/17 13:15, Ryan Sleevi wrote:
> Or, put differently, it sounds as if you suggest the only obligation a CA
> has to ensure their DTP auditors are qualified for the task at hand is if,
> and only if, Mozilla requests those audits. In the absence of that request,
> the CA is allowed to make their own individual determination. Further, it
> seems that you are suggesting that if a CA makes that determination, and
> it's incorrect, that's not a failure upon the CAs part, because they made
> 'a decision', and the relevant portions of Mozilla policy only apply to the
> 'next' audit.

I am saying that, however, undesirable, our current policy could be
interpreted this way, which is why I want to change it. You don't have
to convince me that this situation is undesirable :-)

Gerv

[Ryan Sleevi]

On Fri, Mar 17, 2017 at 5:33 AM Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 16/03/17 13:15, Ryan Sleevi wrote:

> > Or, put differently, it sounds as if you suggest the only obligation a CA
> > has to ensure their DTP auditors are qualified for the task at hand is
> if,
> > and only if, Mozilla requests those audits. In the absence of that
> request,
> > the CA is allowed to make their own individual determination. Further, it
> > seems that you are suggesting that if a CA makes that determination, and
> > it's incorrect, that's not a failure upon the CAs part, because they made
> > 'a decision', and the relevant portions of Mozilla policy only apply to
> the
> > 'next' audit.
>

> I am saying that, however, undesirable, our current policy could be
> interpreted this way, which is why I want to change it. You don't have
> to convince me that this situation is undesirable :-)
>
> Gerv

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Gerv,

I suppose the difficulty I have is I do not believe it can be interpreted
as you suggest, beyond you suggesting it, but without providing evidence as
to how that interpretation is self-consistent with the policy. Could you
perhaps share how you believe that interpretation is reasonable?

[Gervase Markham]

On 07/03/17 11:37, Gervase Markham wrote:
> Here are some proposals for policy change. Please do comment on these or
> suggest others.

I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this
week, there was broad consensus to draw up a ballot which prevents CAs
from (to summarise broadly) outsourcing BR 3.2.2.4 and 3.2.2.5 - domain
name and IP address ownership - validation to third parties, and that
this restriction would be enacted at the level of the BRs, not the level
of Mozilla policy. So I will be working with interested parties from the
Forum to draft some wording that achieves that, as there are various
cases to consider to make sure we don't forbid certain common and secure
activities by accident.

This would be stronger than and therefore supercede:

> Policy Proposal 1: require all CAs to arrange it so that certs validated
> by an RA are issued from one or more intermediates dedicated solely to
> that RA, with such intermediates clearly labelled with the name of the
> RA in the Subject.

Other forms of validation will continue to be outsourceable. Mozilla
does not recognise OV certificates, but when it comes to EV, we do need
to make sure that any outsourcing is properly audited and those audit
findings are properly communicated. How we do this remains an open and
difficult question; however, domain/IP ownership validation is so core
to a CA's activity that it seems wise to remove it from the scope of
this wider problem by banning outsourcing it outright.

I will take up the topic of possible action against Symantec in the
other thread.

Gerv

[Jakob Bohm]

On 24/03/2017 10:56, Gervase Markham wrote:
> On 07/03/17 11:37, Gervase Markham wrote:
>> Here are some proposals for policy change. Please do comment on these or
>> suggest others.
>
> I can report that at the CAB Forum face-to-face in Raleigh, NC, USA this
> week, there was broad consensus to draw up a ballot which prevents CAs
> from (to summarise broadly) outsourcing BR 3.2.2.4 and 3.2.2.5 - domain
> name and IP address ownership - validation to third parties, and that
> this restriction would be enacted at the level of the BRs, not the level
> of Mozilla policy. So I will be working with interested parties from the
> Forum to draft some wording that achieves that, as there are various
> cases to consider to make sure we don't forbid certain common and secure
> activities by accident.
>

One common scenario that a new wording should allow is a "fully
outsourced CA", where all the technical activities, including CA
private key storage, CRL/OCSP distribution, ensuring policy compliance
and domain/IP validation are outsourced to a single entity which is
fully audited as a CA operator, while the entity nominally responsible
for the CA acts more like an RA or reseller.

That "CA operator" might be an actual related CA in good standing, or
might be a professional company created solely for doing this job for
other CAs (such as the private companies that run some government CAs
around the world).

For the "fully outsourced CA" scenario, the things that a normal CA
cannot outsource to a third party would in this case not be allowed to
be "insourced" from the "CA operator" to the nominally responsible
organization.

[Ryan Sleevi]

(Wearing an individual hat)

On Fri, Mar 24, 2017 at 10:35 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> One common scenario that a new wording should allow is a "fully
> outsourced CA", where all the technical activities, including CA
> private key storage, CRL/OCSP distribution, ensuring policy compliance
> and domain/IP validation are outsourced to a single entity which is
> fully audited as a CA operator, while the entity nominally responsible
> for the CA acts more like an RA or reseller.
>

Can you highlight why you believe this is a common scenario? During that
same conversation, only one party was identified that meets such a
definition, and CAs otherwise did not highlight any of their customers or
awareness of others.

[Peter Bowen]

To be fair, we didn't discuss this scenario.

The scenario raised was that CompanyX outsources _all_ CA activities
to CompanyY except for approving CPS changes, writing the management
assertion, and marketing the certificates.

What I believe Jakob is describing is one step less, where CompanyY
does some of the validation steps.

Thanks,
Peter

[Jakob Bohm]

Examples discussed in the past year in this group include the Taiwan
GRCA roots and several of the SubCAs hosted by Verizon prior to the
DigiCert transition.

[Ryan Sleevi]

On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Examples discussed in the past year in this group include the Taiwan
> GRCA roots and several of the SubCAs hosted by Verizon prior to the
> DigiCert transition.

Apologies for not remembering, but I don't recall the relationship of
either of those discussions to what you described. However, it's very easy
I'm wrong.

Could you link to the threads (ideally, the messages) you believe that
captures this description, so that I can better understand?

Peter is correct, we discussed something slightly different, so apologies
for misunderstanding what you were proposing versus what we discussed. It
sounds like what you're describing is what we discussed (white-label),
except the person signing the management assertion is also acting as a
Delegated Third Party for validation. However, because they're the ones
signing the assertion, they're the ones in scope for the audit presented to
root stores - correct?

[Jakob Bohm]

On 24/03/2017 19:08, Ryan Sleevi wrote:
> On Fri, Mar 24, 2017 at 1:30 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Examples discussed in the past year in this group include the Taiwan
>> GRCA roots and several of the SubCAs hosted by Verizon prior to the
>> DigiCert transition.
>
>
> Apologies for not remembering, but I don't recall the relationship of
> either of those discussions to what you described. However, it's very easy
> I'm wrong.
>
> Could you link to the threads (ideally, the messages) you believe that
> captures this description, so that I can better understand?
>

For Taiwan GRCA (Government Root CA) apparently operated by Chungwa
Telecom, this seems most obvious from:

Message-ID:
<mailman.83.1480762782.1...@lists.mozilla.org>
Date: Sat, 3 Dec 2016 00:34:12 -0800 (PST)
From: lcchen...@gmail.com
Subject: Re: Taiwan GRCA Root Renewal Request

For the Verizon rooted tree of multiple CAs, some hosted by Verizon,
some not, look at the long report that is:

Message-ID:
<mailman.489.1478201113.1...@lists.mozilla.org>
Date: Thu, 3 Nov 2016 18:28:10 +0000
From: Jeremy Rowley <jeremy...@digicert.com>
Subject: Update on transition of the Verizon roots and issuance of SHA1
certificates

> Peter is correct, we discussed something slightly different, so apologies
> for misunderstanding what you were proposing versus what we discussed. It
> sounds like what you're describing is what we discussed (white-label),
> except the person signing the management assertion is also acting as a
> Delegated Third Party for validation. However, because they're the ones
> signing the assertion, they're the ones in scope for the audit presented to
> root stores - correct?
>

[Jakob Bohm]

On this second point, there really should be two signed management
assertions and two public audit reports:

One for the "CA Operator", who needs to comply with every bit of the
BR, security and root program policy requirements. The "CA Operator"
must have a CP/CPS for the CA which is verbatim identical to the one
provided by the "CA Owner" and part of the audited CA Operation.
In practice, this would often be a "master" assertion and audit for all
the CAs hosted by that "CA Operator".

One for the "CA Owner", who needs to have a compliant CP/CPS, outsource
to a compliant "CA Operator", meet "Delegated Third Party" audit
requirements for any self-performed functions and provide a management
assertion and other evidence that they don't interfere with the
compliance of the "CA Operator" for their CA(s).

Both parties would have audit reports etc. submitted to the root
programs.

Such a double auditing process would solve most of the problems
commonly caused (according to others) by auditors only dealing with one
of the two parties and the other one falling through the cracks.