RE: Incident Report : GoDaddy certificates with ROCA Fingerprint

[Jeremy Rowley via dev-security-policy]

Hey Alex - we intend to publish a report for the former Symantec certs.  For 
now, here's what I know:

1) The scope was 15 TLS certs. We became aware of the certs through your 
posting.  
2) We are revoking all 15 certs. I'm still waiting for their serial numbers. We 
kicked off the 24 hour period today so they should all be revoked tomorrow.

That's about all I know right now.
Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Friday, October 27, 2017 9:08 AM
To: Daymion Reynolds 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incident Report : GoDaddy certificates with ROCA Fingerprint

Thank you for writing this up.

Do any of the other CAs with trusted server certificates intend to publish 
similar reports? (Based on CT logs that'd be Comodo, Symantec, and GlobalSign).

Alex

On Tue, Oct 24, 2017 at 12:28 PM, Daymion Reynolds via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Godaddy LLC first became aware of possible ROCA vulnerability exposure 
> on Monday October 16th 2017 at 9:30am. The following are the steps we 
> took for detection, revocation, and the permanent fix of certificate 
> provisioning:
>
> •   Monday October 16th 2017 AZ, first became aware of the ROCA
> vulnerability.  We downloaded and modified the open source detection 
> tool to audit 100% of the non-revoked and non-expired certs we had issued.
> •   Early am Wednesday October 18th AZ we had our complete list of 7
> certs with the ROCA defect. We verified the results and proceeded to 
> start the revocation process. While cert revocation was in progress we 
> started researching the long-term detection and prevention of the weak 
> CSR vulnerability.
> •   Early am Wednesday October 18th Rob Stradling released a list of
> certs with the vulnerability. 2/7 we revoked were on the list.
> https://clicktime.symantec.com/a/1/1SkDS7vkKe6aFPef3aMSvQFIofogSXtMjIDOMPSrNdU=?d=y7maDzQwn0t2gfiNBTRLLoxLptvalFLxhxxGV50FFf2HN_GpCO0GEQ5_rJD53axlha3VgyPx5e47idtKKh9Q430x5oQoja_2JjwYYimO70LL-IABmm8rLDDwsSe6D-SQ4vUvLFK8QmovkdoVYa5s4bx_lJw2M8RHGF6MxFEinJ-dFtEuoLiaF_FuBO7KEhoOnoqj2At2y3L-V1_T2U3QXqMynZvbpNH7wBgbuTN89gmguJAKE4Wff-cB1Q590BZYVEFmTUCwDBXXB-aCCKdMZU-CPbiC27t9PqIsHpBTeMTdqeYJIPkES4fzuq6TW8no6Bh0q9461T37F4JqNHK-9ybFxA8-HEacA0WU6u25efXCjiK0bzUgwVRxB9vTYtCoXtet39vQB7YyQRj0Rgyh8TU7keVb3WjzVERe0Pp3r7l3JmD6_4RyNRVIUiI8Kjf9WRn-N0rHOgbvv9p_hin3dr7wSFSS85zlq4g65z0_L1idMgpHVkqfaf33dUSsaghwqNn5=https%3A%2F%2Fmisissued.com%2Fbatch%2F28%2F
> •   Thursday October 19th by 2:02am AZ, we completed the 7 cert
> revocations. Revocations included customer outreach to advise the 
> customer of the vulnerability.
> •   Thursday October 19th AZ, two CSRs were submitted for commonNames “
> scada2.emsglobal.net” & “scada.emsglobal.net” and were issued. Each 
> request had used the vulnerable keys for CSR generation.  We revoked 
> the certs again on Thursday October 19th AZ. During this period, we 
> reached out to the customer to educate them regarding the 
> vulnerability and informing them they needed to generate a new keypair from 
> an unimpacted device.
> Customer was unreachable. Friday October 20thAZ,  another cert was 
> issued for commonName “scada.emsglobal.net” using a CSR generated with 
> a weak key. We then took measures to prevent future certs from being 
> issued to the same common name and revoked the cert on October 20th 2017 AZ.
> commonName   crt.sh-link
> scada.emsglobal.net  
> https://clicktime.symantec.com/a/1/4ypxaC37c0Q-AJ7bui52CmnZ0rpGYzh75RU
> ZYnpk23A=?d=y7maDzQwn0t2gfiNBTRLLoxLptvalFLxhxxGV50FFf2HN_GpCO0GEQ5_rJ
> D53axlha3VgyPx5e47idtKKh9Q430x5oQoja_2JjwYYimO70LL-IABmm8rLDDwsSe6D-SQ
> 4vUvLFK8QmovkdoVYa5s4bx_lJw2M8RHGF6MxFEinJ-dFtEuoLiaF_FuBO7KEhoOnoqj2A
> t2y3L-V1_T2U3QXqMynZvbpNH7wBgbuTN89gmguJAKE4Wff-cB1Q590BZYVEFmTUCwDBXX
> B-aCCKdMZU-CPbiC27t9PqIsHpBTeMTdqeYJIPkES4fzuq6TW8no6Bh0q9461T37F4JqNH
> K-9ybFxA8-HEacA0WU6u25efXCjiK0bzUgwVRxB9vTYtCoXtet39vQB7YyQRj0Rgyh8TU7
> keVb3WjzVERe0Pp3r7l3JmD6_4RyNRVIUiI8Kjf9WRn-N0rHOgbvv9p_hin3dr7wSFSS85
> zlq4g65z0_L1idMgpHVkqfaf33dUSsaghwqNn5=https%3A%2F%2Fcrt.sh%2F%3Fid%
> 3D3084867
>
> scada.emsglobal.net  
> https://clicktime.symantec.com/a/1/OB-olazZASanecDv3efdwDvRV66LosOv7dP
> Crn-2tbc=?d=y7maDzQwn0t2gfiNBTRLLoxLptvalFLxhxxGV50FFf2HN_GpCO0GEQ5_rJ
> D53axlha3VgyPx5e47idtKKh9Q430x5oQoja_2JjwYYimO70LL-IABmm8rLDDwsSe6D-SQ
> 4vUvLFK8QmovkdoVYa5s4bx_lJw2M8RHGF6MxFEinJ-dFtEuoLiaF_FuBO7KEhoOnoqj2A
> t2y3L-V1_T2U3QXqMynZvbpNH7wBgbuTN89gmguJAKE4Wff-cB1Q590BZYVEFmTUCwDBXX
> B-aCCKdMZU-CPbiC27t9PqIsHpBTeMTdqeYJIPkES4fzuq6TW8no6Bh0q9461T37F4JqNH
> K-9ybFxA8-HEacA0WU6u25efXCjiK0bzUgwVRxB9vTYtCoXtet39vQB7YyQRj0Rgyh8TU7
> keVb3WjzVERe0Pp3r7l3JmD6_4RyNRVIUiI8Kjf9WRn-N0rHOgbvv9p_hin3dr7wSFSS85
> zlq4g65z0_L1idMgpHVkqfaf33dUSsaghwqNn5=https%3A%2F%2Fcrt.sh%2F%3Fid%
> 

Re: Francisco Partners acquires Comodo certificate authority business

[Kathleen Wilson via dev-security-policy]

On 11/1/17 12:22 PM, westmai...@gmail.com wrote:

Hello,

Why you're removed the post of Peter Gutmann (Nov. 1, 2017, 4:08)?

If I understand correctly, at the time of the public discussion for new root 
certificates SSL.com (RA Comodo) Mozilla concealed information about the 
acquisition of SSL business of Comodo and that now the past public discussion 
about new root certificates SSL.com can be considered incorrect on this moment 
of time.

Regards,
Andrew.




Please forward the missing email from Peter Gutmann to me.

I do not know if it is related, but we have been experiencing problems 
with groups.google.com:


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

Kathleen

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

RE: Francisco Partners acquires Comodo certificate authority business

[Paul Kehrer via dev-security-policy]

On November 1, 2017 at 2:23:17 PM, westmail24--- via dev-security-policy (
dev-security-policy@lists.mozilla.org) wrote:

Hello,


If I understand correctly, at the time of the public discussion for new
root certificates SSL.com (RA Comodo) Mozilla concealed information about
the acquisition of SSL business of Comodo and that now the past public
discussion about new root certificates SSL.com can be considered incorrect
on this moment of time.


I don't think it's going to be a productive avenue of discussion to imply
Mozilla acted in bad faith with regard to private knowledge of an impending
sale.

If people are seriously concerned by these sorts of transactions I'd urge
them to participate in discussions around mandatory CT as that provides
technical means to document the hypothetical malfeasance they're concerned
about.

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

RE: Francisco Partners acquires Comodo certificate authority business

[westmail24--- via dev-security-policy]

Hello,

Why you're removed the post of Peter Gutmann (Nov. 1, 2017, 4:08)?

If I understand correctly, at the time of the public discussion for new root 
certificates SSL.com (RA Comodo) Mozilla concealed information about the 
acquisition of SSL business of Comodo and that now the past public discussion 
about new root certificates SSL.com can be considered incorrect on this moment 
of time.

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

Re: DRAFT November 2017 CA Communication

[Kathleen Wilson via dev-security-policy]

It has been suggested that I need to communicate to CAs that there will 
be consequences if their audit statements do not meet Mozilla’s 
requirements, so how about if I add the following to the November CA 
Communication?


~~
As stated in Mozilla’s April 2017 CA Communication[1] and Mozilla’s Root 
Store Policy[2, 3] audit statements/letters must meet the following 
requirements or Mozilla will reject the audit statements. And CAs 
without proper and current audit statements will be put on notice and 
potentially removed from Mozilla’s Root Store.


Additionally, audit statements must be provided in English from now on.

As a reminder, here is what Mozilla’s Root Store Policy[2, 3] currently 
says:
“Full-surveillance period-of-time audits MUST be conducted and updated 
audit information provided no less frequently than annually. Successive 
audits MUST be contiguous (no gaps).


The publicly-available documentation relating to each audit MUST contain 
at least the following clearly-labelled information:

- name of the company being audited;
- name and address of the organization performing the audit;
- Distinguished Name and SHA256 fingerprint of each root and 
intermediate certificate that was in scope;
- audit criteria (with version number) that were used to audit each of 
the certificates;
- a list of the CA policy documents (with version numbers) referenced 
during the audit;

- whether the audit is for a period of time or a point in time;
- the start date and end date of the period, for those that cover a 
period of time;

- the point-in-time date, for those that are for a point in time;
- the date the report was issued (which will necessarily be after the 
end date or point-in-time date); and
- For ETSI, a statement to indicate if the audit was a full audit, and 
which parts of the criteria were applied, e.g. DVCP, OVCP, NCP, NCP+, 
LCP, EVCP, EVCP+, QCP-w, Part1 (General Requirements), and/or Part 2 
(Requirements for trust service providers).

“

The above listed information MUST be provided by the auditor in each 
audit statement or its accompanying letter. If the information is 
provided in an accompanying letter, then the pdf file that is submitted 
to Mozilla must contain BOTH the audit statement and the letter.


Please indicate your CA’s understanding that each audit statement/letter 
provided to Mozilla must be in English and must meet the requirements of 
Mozilla’s Root Store Policy, specifically stating the information listed 
above. Otherwise Mozilla will reject the audit statement, and put the CA 
on notice for being out of compliance, which may result in the CA’s root 
certificate(s) being removed from our program.



[1] 
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00018,Q00032


[2] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#audit-parameters


[3] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#public-audit-information


~~


As always, I will appreciate your thoughtful and constructive feedback 
on this suggested addition to the draft of theNovember CA Communication.


Thanks,
Kathleen


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

RE: Francisco Partners acquires Comodo certificate authority business

[Robin Alden via dev-security-policy]

Peter,
As you noted in your post to the cryptography list, Francisco
Partners' website states that they exited from their investment in Blue
Coat.
https://www.franciscopartners.com/investments/blue-coat?sector=Comms-Securit
y=1200

Regards
Robin Alden
Comodo

> -Original Message-
> From: Peter Gutmann
> via dev-security-policy
> Sent: 01 November 2017 04:08
> To: mozilla-dev-security-pol...@lists.mozilla.org; m...@flanga.io
> Subject: Re: Francisco Partners acquires Comodo certificate authority
business
> 
> mw--- via dev-security-policy 
writes:
> 
> >So they sell multiple roots over to a company that is "the leader in Deep
> >Packet Inspection (DPI) and we've got a lot going on in that space" and
> >enable them to issue trusted certificates and mitm all encrypted
connections
> >with that? That is a good halloween joke!
> 
> Francisco Partners is more a general investment company, but in that
regard
> they also have a stake in firms like Blue Coat, whose products have been
used
> by repressive regimes against their citizens.
> 
> Still, it's amusing that a perfect mechanism for performing MITM attacks
is
> now controlled by a company who has other arms that actively perform MITM
> attacks.
> 
> Peter.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Francisco Partners acquires Comodo certificate authority business

[Robin Alden via dev-security-policy]

> -Original Message-
> From: Gerv
> Subject: Re: Francisco Partners acquires Comodo certificate authority
business
> 
> On 31/10/17 13:21, Kyle Hamilton wrote:
> > http://www.eweek.com/security/francisco-partners-acquires-comodo-s-
> certificate-authority-business
> 
> Comodo notified Mozilla of this impending acquisition privately in
> advance, and requested confidentiality, which we granted. Now that the
> acquisition is public, it is reasonable for the community to have a
> discussion about the implications for Mozilla's trust of Comodo, if any.

http://www.businesswire.com/news/home/20171031005584/en/Francisco-Partners-A
nnounces-Acquisition-Comodo%E2%80%99s-Certificate-Authority

We can confirm that a majority stake in Comodo CA Ltd. has been acquired by
Francisco Partners.

The deal has closed, i.e. the transaction is complete.

We are conscious of the requirements of section 8 of the Mozilla Root Store
Policy.

As you have seen from the announcement, we have a new CEO and new Chairman
who have prior experience in managing a trusted CA organization.

There are to be no resultant changes to our CPS, our operations, our
business policies or procedures, or the secure locations from which we
operate our CA infrastructure.

The operational personnel in Comodo CA Limited will not change.  The
certificate validation teams will remain unchanged.

Regards
Robin Alden & Rob Stradling
Comodo CA Ltd.

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

Re: Mozilla’s Plan for Symantec Roots

[Gervase Markham via dev-security-policy]

Hi Peter,

Ryan is the chain-building expert, and others have deeper knowledge of
how the new Symantec/DigiCert PKI is going to work than I do, but here's
an attempt to answer your question.

On 27/10/17 16:51, Peter Bowen wrote:
> If DigiCert generates a new online issuing CA on 20 March 2018 and
> cross-signs it using their VeriSign Class 3 Public Primary
> Certification Authority - G5 offline root CA, will certificates from
> this new issuing CA be trusted by Firefox?  If so, what are the
> parameters of trust, for example not trusted until the new CA is
> whitelisted by Mozilla or only trusted until a certain date?

Certificates chaining up to Symantec roots, so including that Verisign
one, which have notBefore dates after June 2016 (which I assume these
would) will continue to be trusted until the full removal of trust in
Symantec in October 2018.

They may be trusted beyond that if this new issuing CA is one of the
ones DigiCert asks us to whitelist for Symantec continuity (the "Managed
Partner Infrastructure"). Although I'm generally expecting DigiCert to
create and submit a single list of such CAs at one time, rather than
submitting them in dribs and drabs.

> What about the same scenario except the new issuing CA is generated on
> 30 June 2019?

As the Verisign root would no longer be in our root store, certs issued
by such an issuing CA would no longer ordinarily be trusted. If this
were a whitelisted continuity issuing CA, it might still be trusted. If
I recall correctly, the future trust parameters for those continuity CAs
is undefined by the consensus plan. It says that they will continue to
work until any new Symantec hierarchy is in all the root stores, but
that was defined before the purchase was mooted. So it seems to me like
there is now a question mark here.

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

Re: Francisco Partners acquires Comodo certificate authority business

[Gervase Markham via dev-security-policy]

On 31/10/17 13:21, Kyle Hamilton wrote:
> http://www.eweek.com/security/francisco-partners-acquires-comodo-s-certificate-authority-business

Comodo notified Mozilla of this impending acquisition privately in
advance, and requested confidentiality, which we granted. Now that the
acquisition is public, it is reasonable for the community to have a
discussion about the implications for Mozilla's trust of Comodo, if any.

However, there is also another wrinkle to iron out. Our policy 2.5 says:
"If the receiving or acquiring company is new to the Mozilla root
program, there MUST be a public discussion regarding their admittance to
the root program, which Mozilla must resolve with a positive conclusion
before issuance is permitted."

I personally feel that this is a bug, in that technically it says that
as soon as a deal closes and is announced, the CA has to stop issuance
entirely until the Mozilla community has had a discussion and given the
OK. I believe that's not reasonable and would create massive business
disruption if the letter of that rule were enforced strictly. I think
that when we wrote the policy, we didn't anticipate the situation where
the buyer would be confidential until closing. (Compare Digimantec,
where it's not.)

So it would also be useful to have a discussion about what this section
of the policy should actually say.

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

Re: ETSI audits not listing audit periods

[Arno Fiedler via dev-security-policy]

Am Montag, 30. Oktober 2017 22:19:31 UTC+1 schrieb Ryan Sleevi:
> On Mon, Oct 30, 2017 at 3:50 PM, Kathleen Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > How do we get all auditors to start meeting our audit statement
> > requirements?
> >
> > Why haven't all included CAs communicated these requirements to their
> > auditors?
> >
> > Why am I seeing so many audit statements (particularly ETSI audit
> > statements) that do not meet our requirements?
> >
> > I will greatly appreciate thoughtful and constructive ideas on this.
> >
> > Thanks,
> > Kathleen
> >
> 
> Kathleen,
> 
> Thanks for raising this matter! I think it's an important highlighting of
> the very different approaches to auditing employed by WebTrust and ETSI,
> and the underlying reliability and assurance of those audits.
> 
> Below is my attempt to summarize my understanding so far:
> - ETSI EN 319 411-1 specifies generally applicable policy and security
> requirements for trust service providers (TSPs) - including website
> certificates.
> - The purpose of EN 319 411-1 is to provide a framework for assessment of a
> TSP, but does not specify how that assessment is to be caried out (c.f.
> Section 1 of EN 319 411-1)
> - EN 319 411-1 mentions EN 319 403 for guidance on such assessments
> - EN 319 403 provides the framework for conformity assessment bodies (CABs)
> to evaluate TSPs. It's based on/extends ISO/IEC 17065 specific to TSPs.
> - ISO/IEC 17065 is incorporated due to Regulation (EC) No 765/2008 to
> ensure consistency in CABs in evaluating TSPs
> 
> As noted within 319 403 (Introduction), several other documents are
> incorporated as well - ISO/IEC 17021 (common requirements for conformity
> assessment bodies evaluating management systems) and ISO/IEC 27006 (common
> requirements for CABs evaluating information security management systems),
> for example.
> 
> If we put the layer cake together and simplify:
> * ISO/IEC 17065 - Common requirements for conformity assessment bodies
> looking at products/services (e.g. "What should all auditors do")
> * ISO/IEC 17021 - Common requirements for conformity assessment bodies
> looking at management systems
> * ISO/IEC 27006 - Common requirements for conformity assessment bodies
> looking at information security management systems
> * EN 319 403 - Common requirements for conformity assessment bodies
> evaluating TSPs (e.g. "What makes an auditor qualified to be a CA auditor")
> * EN 319 411-1 - Common requirements on the TSP for websites (combined with
> EN 319 401, which 319 411-1 incorporates-and-builds-on)
> 
> In trying to understand why the reports are what they are, we need to look
> in particular at 17021 and 17065, and the framework they use for both audit
> engagements and reporting. 17065 describes a certification scheme.
> Reproducing a paragraph from the introduction:
> 
> """
> Certification of products, processes or services is a means of providing
> assurance that they comply with
> specified requirements in standards and other normative documents. Some
> product, process or service
> certification schemes may include initial testing or inspection and
> assessment of its suppliers' quality
> management systems, followed by surveillance that takes into account the
> quality management system and
> the testing or inspection of samples from the production and the open
> market. Other schemes rely on initial
> testing and surveillance testing, while still others comprise type testing
> only.
> """
> 
> 319 411-1 certification describes a system that is based on an initial
> testing or inspection, along with periodic surveillance. Importantly,
> within 17065 and 17021, the way of ensuring continued compliance is done
> based on contracts and reporting - that is, the client is responsible for
> reporting changes to their conformity assessment body, and the CAB may
> determine to revoke the certification or indicate corrective actions should
> be taken (see ISO/IEC 17065:2012(E) 4.1.2.2, ISO/IEC 17021:2006(E) 8.6.3).
> ISO/IEC 17065:2012(E), Section 7.7 describes the general reporting: the
> name of the CAB, the date the certification is granted, the name and
> address of the client, the scope of the certification, the validity
> period/expiration date of the certificate, and anything else required by
> the certification scheme (319 411-1).
> 
> Within the WebTrust scheme, the reports are based on either US (AICPA)
> Standards of AT101, Canadian (CPA Canada) Standards of Section 5025, or
> IFAC's ISAE3000 standards. What is important and notable about these is
> that they are reports over information, with a scope and norm (e.g.
> WebTrust for CAs) applied. This is why there's a consistent period of time
> - information is collected and the auditor evaluates, on the basis of that
> information, the level of assurance that is being met.
> 
> I'm still working to have a better understanding here (and this is all in a
> personal capacity), but my 

Re: ETSI Audits Almost Always FAIL to list audit period

[Dimitris Zacharopoulos via dev-security-policy]

This is a long thread but the topic is very critical so I hope people 
are patient enough to read through this long discussion.


On 1/11/2017 12:37 πμ, Ryan Sleevi wrote:



On Tue, Oct 31, 2017 at 5:29 PM, Dimitris Zacharopoulos via 
dev-security-policy > wrote:


I don't believe your statement is supported by the evidence -
which is why
I'm pushing you to provide precise references. Consider from the
perspective as a consumer of such audits - there is zero
awareness of the
contract as to whether or not the BRs were in scope - after
all, 319 411-1
is meant to be inclusive of the normative requirements with
respect to
audit supervision.


My statement that auditors are governed by 17065 and 403 is
supported by evidence (section1 of 411-1 where it says that ETSI
EN 319 403 provides guidance to auditors that wish to audit the
411-1 standard). Also, the BRs are normative for 411-1 as stated
in section 2.1 of the same document. Normative references to the
BRs are all over the 411-1 document, unless I misunderstood your
statement.


I think you did, so I'll try to repeat.

As you know, for both ETSI and WebTrust criteria, what is normative is 
the requirements within the respective documents. That is, regardless 
of what the BRs say (or don't say), what is audited is the criteria. 
Section 2.1 lists the BRs as a normative reference, but that is 
because specific auditable criteria are derived from it, not because 
it's fully incorporated by reference. That is, if you imagine a ballot 
passing the CABF (which itself is hard to imagine) that said "CAs 
shall keep a rubber duck next to the HSM", and it was adopted, this 
wouldn't necessarily immediately cause ETSI or WebTrust audits to 
fail, because that requirement hasn't yet had an auditable criteria 
derived from it. That's why I'm suggesting that, for sake of 
discussion, auditors ignore whats in the BRs - unless specifically 
told (by the WebTrust or ETSI documents) to examine specific sections.


As to "whether or not they were in scope", my point was that a 319 
403/401 audit has the contract define the scope of the period and 
activities, and that's not part of the final reporting mechanism. As 
such, there's no public attestation as to the period of evidence 
examined. I expand on that more below.


But stepping back further from the contract, the claim that
"the audit
covers operations for one year" is also not part of the 17065,
17021, or
319 403 oversight. That is, the certification is forward
looking (as
evidenced by the expiration), and while it involves historic
review, it is
not, in and of itself, a statement of assurance of the
historic activities.
This is the core difference between the 17021/17065 evaluation
of processes
and products versus, say, the ISAE3000 assurance evaluation.


I read the ISAE3000 and can't find specific language to support a
core difference in auditor guidance, especially related to the
assurance of the historic activities. Perhaps there is a more
specific section you can reference.


http://www.ifac.org/system/files/downloads/b012-2010-iaasb-handbook-isae-3000.pdf

Pages 304 and 305
Assurance Report Content
49. The assurance report should include the following basic elements:
...
(c) An identification and description of the subject matter information
and, when appropriate, the subject matter: this includes for example:
The point in time or period of time to which the evaluation or
measurement of the subject matter relates;



Sure, this is about the contents of the report and it's a "should". From 
a RP perspective, I perfectly understand the concern being raised here 
that critical information (as the audit period) is missing from some 
ETSI reports (as Kathleen said, there are good ETSI reports that include 
this information) but audit reports are one thing and raising concerns 
about the audit scheme is another.




The eIDAS Regulation mandates for 2-year audits (not the
ETSI EN 319
411-1). This has been reflected in the ETSI EN 319 403
audit scheme, under
7.4.6 (Audit Frequency), which states:

"There shall be a period of no greater than two years for
a full
(re-)assessment audit unless otherwise required by the
applicable
legislation or commercial scheme applying the present
document.

NOTE: A surveillance audit can be required by an entitled
party at any
time or by the conformity assessment
body as defined by the surveillance programme according to
clause 7.9."

I'm patently aware of that, but I'm trying to