Re: ETSI Audits Almost Always FAIL to list audit period

[Arno Fiedler via dev-security-policy]

Am Dienstag, 31. Oktober 2017 10:21:47 UTC+1 schrieb Dimitris Zacharopoulos:
> It is not the first time this issue is brought up. While I have a very 
> firm opinion that ETSI auditors under the ISO 17065 (focused on the 
> quality of products/services) and ETSI EN 319 403 definitely check 
> historical data to assess the level of conformance, I will communicate 
> this to our auditor and ask if they would like to provide more specific 
> feedback.
> 
> During the CA/Browser Forum F2F 41 in Berlin, it was stated that TUV-IT 
> (CAB and chair in ACAB-c), was in discussions with Root Programs to 
> determine an "ETSI audit report template" that would include all 
> critical information that Root programs would like to be included in the 
> public (or browser) audit letter/report. Minutes 
> (https://cabforum.org/2017/06/21/2017-06-21-f2f-minutes-meeting-41-berlin/)
> 
> --- BEGIN QUOTE ---
> 
> Clemens Wanko from TÜVIT/ACABc – “Update: Addressing Browser Audit 
> Requirements under eIDAS/ETSI”
> 
> Clemens said that there were several discussions with the Browsers that 
> resulted in an audit report template that would meet the Browser’s 
> expectations.
> 
> Dimitris asked if this template could be posted on the public mailing list.
> 
> --- END QUOTE ---
> 
> Until today, such a template has not been published or circulated either 
> in the CA/Browser Forum or the m.d.s.p. I hope this discussion will push 
> for this template to be published.
> 
> I believe the issue being raised here is more of an audit report issue 
> and not of audit criteria. Auditors under the ETSI audit scheme, just as 
> with the Webtrust scheme, in order for the audit to be "effective", must 
> obtain evidence of actions that took place in the past. How far back, 
> should be determined by the audit criteria and requirements. For 
> example, the Baseline Requirements and Root programs require a full 
> audit to occur once a year which means auditors must collect evidence 
> from "at least" one year. Auditors may examine evidence even further 
> back if they consider that this is required in order for them to get a 
> better understanding of CA operations for their assessment.
> 
> Also check Section 7.9 Surveillance (ETSI EN 319 403): "In addition, a 
> sample of records relating to the operation of TSP over the historical 
> period since the previous audit shall be examined by the auditor".
> 
> The 17065 scheme is used to assess products like food. You can't make an 
> effective assessment in such a critical area by just looking at the 
> "current status" without looking at historical data. In the ETSI/ISO 
> audit schemes, CABs are supervised and audited by National Accreditation 
> Bodies (NABs), at least annually which provides some extra level of 
> assurance that the audits conducted by CABs are examined by an 
> independent party. NABs also have the right to witness audits conducted 
> by CABs.
> 
> Finally, when a CA changes audit criteria, like the Firmaprofesional 
> case, the audit is by definition a point-in-time (system bootstrap) for 
> that specific audit standard. However, it is very likely that their 
> auditors checked historical information to complete their assessment. 
> This is poorly communicated in their audit report but we have seen 
> updated reports in the past, clarifying these issues.
> 
> 
> Dimitris.
> 
> 
> PS: I hope we are not mixing audit failures, that are likely to occur in 
> all audit standards, with audit criteria.
> 
> 
> On 30/10/2017 9:16 μμ, Kathleen Wilson via dev-security-policy wrote:
> > All,
> >
> > It is extremely frustrating to deal with ETSI audits, because they 
> > typically do not specifically state the audit period start and end dates. 
> > And it is very difficult to determine if their audit statement is for a 
> > point-in-time audit versus a period-of-time audit.
> >
> > They have a concept of their ETSI certification being valid for one year, 
> > and will list an expiration date for their ETSI certification that is in 
> > the future. Many of the CAs mistakenly enter their ETSI certification dates 
> > for the audit period start and end dates.
> >
> > This is an ongoing problem that I'm very frustrated with.
> >
> > ~~
> >
> > Definition (From BRs):
> > Audit Period: In a period‐of‐time audit, the period between the first day 
> > (start) and the last day of operations (end) covered by the auditors in 
> > their engagement. (This is not the same as the period of time when the 
> > auditors are on‐site at the CA.)"
> >
> > ~~
> >
> > Here is the requirement according to the Baseline Requirements:
> > https://cabforum.org/baseline-requirements-documents/
> > Section 8.1:"The period during which the CA issues Certificates SHALL be 
> > divided into an unbroken sequence of audit periods.
> > An audit period MUST NOT exceed one year in duration."
> >
> > Here's the requirement according to Mozilla's Policy:
> > 

Re: Estonia e-residency instructing users not to update Firefox (on Mac)

[Gervase Markham via dev-security-policy]

On 02/11/17 11:39, Henri Sivonen wrote:
> A Medium post claiming[1] to represent Estonia e-residency
> https://medium.com/e-residency-blog/estonia-is-enhancing-the-security-of-its-digital-identities-361b9a3c9c52
> instructs Mac users not to update Firefox from December 15 2017 onwards.

Thank you for this report; the Estonian e-residency team has updated the
blog post to remove the advice about not updating Firefox.

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

RE: DigiCert ROCA fingerprint incident report

[Jeremy Rowley via dev-security-policy]

More info (that was sent to me a while ago, I just missed the report):

There we actually seven. I missed this one:
Serial: "a18e9"

We installed a patch to stop accepting ROCA keys for TLS certs on
2017-10-26.  A patch for code signing and email certs is coming shortly.
Once that patch is installed, we will repeat our scans for any additional
vulnerable certificates that were issued in the interim.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, November 7, 2017 11:40 AM
To: Kurt Roeckx 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: DigiCert ROCA fingerprint incident report

Yeah - still trying to get that info. I'll update this list right when I
know what's been done.  I'm not 100% sure at this point, but I wanted to
post early and update than wait until I know everything.  Sorry - should
have specified that in the original email.

-Original Message-
From: Kurt Roeckx [mailto:k...@roeckx.be]
Sent: Tuesday, November 7, 2017 11:38 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert ROCA fingerprint incident report

Hi,

What I miss is what has been done to prevent new ones from being issued.


Kurt

On Tue, Nov 07, 2017 at 06:20:53PM +, Jeremy Rowley via
dev-security-policy wrote:
> Hey everyone,
> 
>  
> 
> Here's the DigiCert incident report about the ROCA fingerprints. Note 
> that these were all issued by Symantec (ie, before the transaction
closed).
> 
>  
> 
> We became aware of the issue when it was posted to the mailing list.
> However, at that time, the certs were not operated by DigiCert. We 
> became aware that DigiCert needed to take action on close (Nov 1).  At 
> that time, the new combined team launched an investigation to 
> determine the impacted certs. Six certs were identified and revoked:
> 
>  
> 
> 
> 4a907fbfc90eb043c50c9c8ace6305a1
> 
> 
> 8008c178d0d4cd3d79acc09f6ac132c
> 
> 
> 2dab9a2d40a2f55c5d705551cf7cafe5
> 
> 
> 306b67f5c25ee0fd495d2be88979eb72
> 
> 
> 7c7b826b183093ba1e5b9850ac31d806
> 
> 
> 4c834767e44ecbd0cdef8e60c04dcf32
> 
>  
> 
> These certs were all revoked around Nov 3, within 24 hours of 
> identifying the impacted certs at DigiCert.
> 
>  
> 
> Jeremy
> 



> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/ac3GKpOQNNTUgvdrINCg5TSocQpoIoCYQJm
> i6wdzR6s=?d=x6aCRo4VfXwciHJ72iOM_J1K3cmxLlV0aGOHiskoYAX0y17Wq9rBdSq-bg
> 4GrKAujQl5VZlxkGBYh01ZXYr8EygG-dNtE90f1YxT_GtuW58TCPLm7Mzjb03dlIVjjY5-
> Rjwup4G6ykol-8HJAhLROxtb1Gda2q-q68_5E0-B8lD0Vce3ByqdfnbDVs8EMtgtnbEqDO
> 6mDPSrslcUjJVelIOpVaxXMdNiBwpMKzmrMdj_V1r1S7QZYgVhUMqQIdLCSpsF3J_80G4P
> 0pGEj80fNBSwYUExVrYXgahNhnXwZBZ2uStpa7rDf1Za_6AmZUyOBJKYnpBkOQOvL_7APz
> 7ZWMYjlryr5kvZwlfwT2ceDE2ZfuZyVEaDmygE8KnF=https%3A%2F%2Flists.mozil
> la.org%2Flistinfo%2Fdev-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: DigiCert ROCA fingerprint incident report

[Jeremy Rowley via dev-security-policy]

Yeah - still trying to get that info. I'll update this list right when I
know what's been done.  I'm not 100% sure at this point, but I wanted to
post early and update than wait until I know everything.  Sorry - should
have specified that in the original email.

-Original Message-
From: Kurt Roeckx [mailto:k...@roeckx.be] 
Sent: Tuesday, November 7, 2017 11:38 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert ROCA fingerprint incident report

Hi,

What I miss is what has been done to prevent new ones from being issued.


Kurt

On Tue, Nov 07, 2017 at 06:20:53PM +, Jeremy Rowley via
dev-security-policy wrote:
> Hey everyone,
> 
>  
> 
> Here's the DigiCert incident report about the ROCA fingerprints. Note 
> that these were all issued by Symantec (ie, before the transaction
closed).
> 
>  
> 
> We became aware of the issue when it was posted to the mailing list.
> However, at that time, the certs were not operated by DigiCert. We 
> became aware that DigiCert needed to take action on close (Nov 1).  At 
> that time, the new combined team launched an investigation to 
> determine the impacted certs. Six certs were identified and revoked:
> 
>  
> 
> 
> 4a907fbfc90eb043c50c9c8ace6305a1
> 
> 
> 8008c178d0d4cd3d79acc09f6ac132c
> 
> 
> 2dab9a2d40a2f55c5d705551cf7cafe5
> 
> 
> 306b67f5c25ee0fd495d2be88979eb72
> 
> 
> 7c7b826b183093ba1e5b9850ac31d806
> 
> 
> 4c834767e44ecbd0cdef8e60c04dcf32
> 
>  
> 
> These certs were all revoked around Nov 3, within 24 hours of 
> identifying the impacted certs at DigiCert.
> 
>  
> 
> Jeremy
> 



> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/ac3GKpOQNNTUgvdrINCg5TSocQpoIoCYQJm
> i6wdzR6s=?d=x6aCRo4VfXwciHJ72iOM_J1K3cmxLlV0aGOHiskoYAX0y17Wq9rBdSq-bg
> 4GrKAujQl5VZlxkGBYh01ZXYr8EygG-dNtE90f1YxT_GtuW58TCPLm7Mzjb03dlIVjjY5-
> Rjwup4G6ykol-8HJAhLROxtb1Gda2q-q68_5E0-B8lD0Vce3ByqdfnbDVs8EMtgtnbEqDO
> 6mDPSrslcUjJVelIOpVaxXMdNiBwpMKzmrMdj_V1r1S7QZYgVhUMqQIdLCSpsF3J_80G4P
> 0pGEj80fNBSwYUExVrYXgahNhnXwZBZ2uStpa7rDf1Za_6AmZUyOBJKYnpBkOQOvL_7APz
> 7ZWMYjlryr5kvZwlfwT2ceDE2ZfuZyVEaDmygE8KnF=https%3A%2F%2Flists.mozil
> la.org%2Flistinfo%2Fdev-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: DigiCert ROCA fingerprint incident report

[Kurt Roeckx via dev-security-policy]

Hi,

What I miss is what has been done to prevent new ones from being
issued.


Kurt

On Tue, Nov 07, 2017 at 06:20:53PM +, Jeremy Rowley via dev-security-policy 
wrote:
> Hey everyone, 
> 
>  
> 
> Here's the DigiCert incident report about the ROCA fingerprints. Note that
> these were all issued by Symantec (ie, before the transaction closed).
> 
>  
> 
> We became aware of the issue when it was posted to the mailing list.
> However, at that time, the certs were not operated by DigiCert. We became
> aware that DigiCert needed to take action on close (Nov 1).  At that time,
> the new combined team launched an investigation to determine the impacted
> certs. Six certs were identified and revoked:
> 
>  
> 
> 
> 4a907fbfc90eb043c50c9c8ace6305a1
> 
> 
> 8008c178d0d4cd3d79acc09f6ac132c
> 
> 
> 2dab9a2d40a2f55c5d705551cf7cafe5
> 
> 
> 306b67f5c25ee0fd495d2be88979eb72
> 
> 
> 7c7b826b183093ba1e5b9850ac31d806
> 
> 
> 4c834767e44ecbd0cdef8e60c04dcf32
> 
>  
> 
> These certs were all revoked around Nov 3, within 24 hours of identifying
> the impacted certs at DigiCert. 
> 
>  
> 
> Jeremy
> 



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

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

RE: DigiCert ROCA fingerprint incident report

[Jeremy Rowley via dev-security-policy]

I believe so – I asked that they all be logged, but I’ll need to double check 
whether it got done. 

 

From: Alex Gaynor [mailto:agay...@mozilla.com] 
Sent: Tuesday, November 7, 2017 11:23 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert ROCA fingerprint incident report

 

Hi Jeremy,

 

Have all these certificates been submitted to CT?

 

Thanks!

Alex

 

On Tue, Nov 7, 2017 at 1:20 PM, Jeremy Rowley via dev-security-policy 
 > wrote:

Hey everyone,



Here's the DigiCert incident report about the ROCA fingerprints. Note that
these were all issued by Symantec (ie, before the transaction closed).



We became aware of the issue when it was posted to the mailing list.
However, at that time, the certs were not operated by DigiCert. We became
aware that DigiCert needed to take action on close (Nov 1).  At that time,
the new combined team launched an investigation to determine the impacted
certs. Six certs were identified and revoked:




4a907fbfc90eb043c50c9c8ace6305a1


8008c178d0d4cd3d79acc09f6ac132c


2dab9a2d40a2f55c5d705551cf7cafe5


306b67f5c25ee0fd495d2be88979eb72


7c7b826b183093ba1e5b9850ac31d806


4c834767e44ecbd0cdef8e60c04dcf32



These certs were all revoked around Nov 3, within 24 hours of identifying
the impacted certs at DigiCert.



Jeremy


___
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: DigiCert ROCA fingerprint incident report

[Alex Gaynor via dev-security-policy]

Hi Jeremy,

Have all these certificates been submitted to CT?

Thanks!
Alex

On Tue, Nov 7, 2017 at 1:20 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hey everyone,
>
>
>
> Here's the DigiCert incident report about the ROCA fingerprints. Note that
> these were all issued by Symantec (ie, before the transaction closed).
>
>
>
> We became aware of the issue when it was posted to the mailing list.
> However, at that time, the certs were not operated by DigiCert. We became
> aware that DigiCert needed to take action on close (Nov 1).  At that time,
> the new combined team launched an investigation to determine the impacted
> certs. Six certs were identified and revoked:
>
>
>
>
> 4a907fbfc90eb043c50c9c8ace6305a1
>
>
> 8008c178d0d4cd3d79acc09f6ac132c
>
>
> 2dab9a2d40a2f55c5d705551cf7cafe5
>
>
> 306b67f5c25ee0fd495d2be88979eb72
>
>
> 7c7b826b183093ba1e5b9850ac31d806
>
>
> 4c834767e44ecbd0cdef8e60c04dcf32
>
>
>
> These certs were all revoked around Nov 3, within 24 hours of identifying
> the impacted certs at DigiCert.
>
>
>
> Jeremy
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

DigiCert ROCA fingerprint incident report

[Jeremy Rowley via dev-security-policy]

Hey everyone, 

 

Here's the DigiCert incident report about the ROCA fingerprints. Note that
these were all issued by Symantec (ie, before the transaction closed).

 

We became aware of the issue when it was posted to the mailing list.
However, at that time, the certs were not operated by DigiCert. We became
aware that DigiCert needed to take action on close (Nov 1).  At that time,
the new combined team launched an investigation to determine the impacted
certs. Six certs were identified and revoked:

 


4a907fbfc90eb043c50c9c8ace6305a1


8008c178d0d4cd3d79acc09f6ac132c


2dab9a2d40a2f55c5d705551cf7cafe5


306b67f5c25ee0fd495d2be88979eb72


7c7b826b183093ba1e5b9850ac31d806


4c834767e44ecbd0cdef8e60c04dcf32

 

These certs were all revoked around Nov 3, within 24 hours of identifying
the impacted certs at DigiCert. 

 

Jeremy



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: Third party use of OneCRL

[Ryan Sleevi via dev-security-policy]

Apologies, my understanding is that the XML is synced from the JSON, rather
than the other way around

See https://wiki.mozilla.org/Firefox/Kinto#Blocklists

That is, the canonical source is Kinto (JSON), that is then used to drive
the generation of the blocklist.xml (so that released binaries match the
remotely-provided blocklist at the time of binary release)

You can see an example of a OneCRL modification at
https://bugzilla.mozilla.org/show_bug.cgi?id=1407559 - in which Kinto is
updated with the new set, and then that propagates to the blocklist.xml

On Tue, Nov 7, 2017 at 9:58 AM, Niklas Bachmaier <
niklas.bachma...@googlemail.com> wrote:

> Thanks a lot, Ryan! Your comment on the Firefox specific selection of
> revoked certificates contained in the list is definitely a point we'll have
> to consider.
> One more question: do I see it correctly that what is being called OneCRL
> is the "certItems" part of https://hg.mozilla.org/
> mozilla-central/file/tip/browser/app/blocklist.xml? And the link which
> provides the JSON file (which I included in my message before) is derived
> from the blocklist XML?
>
> 2017-11-07 14:47 GMT+01:00 Ryan Sleevi :
>
>> Note that additions and removals are made in OneCRL relate to the
>> behaviour of mozilla::pkix and the trust lists expressed by the associated
>> version of NSS shipping with the supported versions of Firefox.
>>
>> For example, this includes revocation of 'email only' CAs (that are not
>> appropriately constrained), which of course would not be appropriate for an
>> e-mail consuming application, or the revocation of particular
>> cross-certificates tied to the status of trust of particular roots.
>>
>> As for the blocklist update, it's maintained in
>> https://hg.mozilla.org/mozilla-central/filelog/tip/browse
>> r/app/blocklist.xml
>>
>> On Tue, Nov 7, 2017 at 8:08 AM, niklas.bachmaier--- via
>> dev-security-policy  wrote:
>>
>>> Hi all
>>>
>>> I'm working for a big managed security provider. We would like to
>>> benefit from OneCRL as a means of improving our certificate revocation
>>> checking.
>>>
>>> I could download OneCRL at https://firefox.settings.servi
>>> ces.mozilla.com/v1/buckets/blocklists/collections/certificates/records.
>>> My question is if there is a license on OneCRL or if we are free to use it?
>>> Further I'm wondering if Mozilla has already thought about third party
>>> users and provides another way of getting the most recent version of OneCRL
>>> than getting the above mentioned website and comparing if the content has
>>> changed?
>>>
>>> Thanks a lot already for any feedback on this!
>>>
>>> Niklas
>>> ___
>>> dev-security-policy mailing list
>>> dev-security-policy@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-security-policy
>>>
>>
>>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Third party use of OneCRL

[Niklas Bachmaier via dev-security-policy]

Thanks a lot, Ryan! Your comment on the Firefox specific selection of
revoked certificates contained in the list is definitely a point we'll have
to consider.
One more question: do I see it correctly that what is being called OneCRL
is the "certItems" part of
https://hg.mozilla.org/mozilla-central/file/tip/browser/app/blocklist.xml?
And the link which provides the JSON file (which I included in my message
before) is derived from the blocklist XML?

2017-11-07 14:47 GMT+01:00 Ryan Sleevi :

> Note that additions and removals are made in OneCRL relate to the
> behaviour of mozilla::pkix and the trust lists expressed by the associated
> version of NSS shipping with the supported versions of Firefox.
>
> For example, this includes revocation of 'email only' CAs (that are not
> appropriately constrained), which of course would not be appropriate for an
> e-mail consuming application, or the revocation of particular
> cross-certificates tied to the status of trust of particular roots.
>
> As for the blocklist update, it's maintained in https://hg.mozilla.org/
> mozilla-central/filelog/tip/browser/app/blocklist.xml
>
> On Tue, Nov 7, 2017 at 8:08 AM, niklas.bachmaier--- via
> dev-security-policy  wrote:
>
>> Hi all
>>
>> I'm working for a big managed security provider. We would like to benefit
>> from OneCRL as a means of improving our certificate revocation checking.
>>
>> I could download OneCRL at https://firefox.settings.servi
>> ces.mozilla.com/v1/buckets/blocklists/collections/certificates/records.
>> My question is if there is a license on OneCRL or if we are free to use it?
>> Further I'm wondering if Mozilla has already thought about third party
>> users and provides another way of getting the most recent version of OneCRL
>> than getting the above mentioned website and comparing if the content has
>> changed?
>>
>> Thanks a lot already for any feedback on this!
>>
>> Niklas
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ETSI audits not listing audit periods

[Jakob Bohm via dev-security-policy]

On 06/11/2017 17:05, m.wiedenho...@tuvit.de wrote:

TÜViT as a conformity assessment body would like to add some explanations to 
clear up some misunderstandings about ETSI auditing.
First of all, we would like to give one preliminary remark. ETSI has separated 
the TSP technical requirements (ETSI EN 319 411-1, ETSI EN 319 401) from the 
CAB auditing requirements (ETSI EN 319 403). This is an ISO international 
standardization best practice (principle 1 of ISO / IEC 17007) not to mix 
technical requirements (“what to audit”) with auditing requirements (“how to 
perform such audits”).

Given that, the main issue of this thread seems to be the question about the 
point-in-time vs. period-of-time audit approach.
Of course, every properly conducted audit has to include and examine the 
point-in-time situation at the time of the current audit. But beyond that, every 
properly conducted audit must cover the operations performed since the last audit. 
The latter is defined by ETSI EN 319 403. In its section 7.9 it deals with 
surveillance and re-assessment. It has already been agreed upon without objections 
(during the CABF F2F Bilbao meeting, if we remember correctly) that only annual 
full system audits are eligible in the context of CABF BR and/or EVG. As a 
consequence, every audit (aside from the very first initial audit => 
point-in-time / pre-issuance readiness assessment) must be performed as 
re-assessment and the relaxations for surveillance audits introduced in this 
section do not apply in the BR / EVG context. In its last sentence this section 
declares, that auditors must cover a sample of records on the operations performed 
since the previous audit.
It is our firm opinion, shared by our national accreditation body, that this 
defines an audit period ranging from the date of the last audit up to the date 
of the current audit and that the complete period needs to be examined, not 
only certain bits and pieces of it. However, if the current phrase is causing 
problems, we are absolutely willing to approach ETSI in order to request an 
explicit clarification of this in a future version of the standard.
As you correctly pointed out, the ETSI EN 319 403 in section 7.10 includes a 
notification scheme, where the CA’s are required to notify changes affecting 
the certification to the conformity assessment body. But as stated above, this 
is not a replacement for the backward-looking period-of-time audit approach. It 
is a supplement in order to perform auditing of security-relevant changes (and 
identify changes that would be non-conformant!) in a timely manner and not only 
at the next annual full audit.
Summarizing this, a properly conducted ETSI audit includes both point-in-time 
and period-of-time (and the latter both backward- as well as forward-).

Another issue obviously is the proper format of a publicly facing audit report 
/ audit attestation to be presented to the root programs.
With this we are totally on your side, an acceptable report / attestation must 
clearly state the required facts in order to enable to deal with it. These 
reports are not and cannot be completely defined in the ETSI EN 319 403 
standard, as different use cases (“consumers”) might require different sets of 
information.
However, in our opinion the CABF and browser root programs give sufficient 
information about the required contents. We are willing to readopt the idea of 
creating a mandatory template for such audit attestation. This idea had been in 
the field since some CABF F2F-Meetings but obviously has never been finalized. 
Root programs could then simply decline all attestations that do not conform to 
the template.
We are open to further discussions, e.g. at the next CA-Day 
(https://www.tuvit.de/en/news/events/events-detail/details/9-ca-day-2017/) or 
at any upcoming CABF F2F meeting.

Best regards
Matthias Wiedenhorst, TÜViT



(This is my interpretation, I don't have authority on this):

The biggest issue (in this thread at least), is that a number of "public
audit reports" (the portion of an audit that are signed by the auditor
and published by the audited CA/TSP) lack the following 3 pieces of
basic information:

1. The specific date of the previous audit (the start of the period
  covered by a period-in-time audit), thus making it impossible for
  readers of such reports to determine if they did not receive or
  otherwise missed a period-in-time audit covering a previous period
  (the requirements for the Mozilla root program allow, and in rare
  cases require, period-in-time audits more frequently than 1/year).

2. A simple statement that this is a period-in-time audit covering the
  period from the stated date (see #1) to the "audit date" and not a
  point-in-time audit for the "audit date" only.

3. For audits referring to the older ETSI audit regime (not the current
  regime it appears), a statement that the audit was an actual full
  audit with period-in-time checking etc. and not a 

Re: Third party use of OneCRL

[Ryan Sleevi via dev-security-policy]

Note that additions and removals are made in OneCRL relate to the behaviour
of mozilla::pkix and the trust lists expressed by the associated version of
NSS shipping with the supported versions of Firefox.

For example, this includes revocation of 'email only' CAs (that are not
appropriately constrained), which of course would not be appropriate for an
e-mail consuming application, or the revocation of particular
cross-certificates tied to the status of trust of particular roots.

As for the blocklist update, it's maintained in
https://hg.mozilla.org/mozilla-central/filelog/tip/browser/app/blocklist.xml

On Tue, Nov 7, 2017 at 8:08 AM, niklas.bachmaier--- via dev-security-policy
 wrote:

> Hi all
>
> I'm working for a big managed security provider. We would like to benefit
> from OneCRL as a means of improving our certificate revocation checking.
>
> I could download OneCRL at https://firefox.settings.
> services.mozilla.com/v1/buckets/blocklists/collections/certificates/
> records. My question is if there is a license on OneCRL or if we are free
> to use it? Further I'm wondering if Mozilla has already thought about third
> party users and provides another way of getting the most recent version of
> OneCRL than getting the above mentioned website and comparing if the
> content has changed?
>
> Thanks a lot already for any feedback on this!
>
> Niklas
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: ETSI Audits Almost Always FAIL to list audit period

[Buschart, Rufus via dev-security-policy]

 For example, in all our audits for other standards, no “audit 
 period” is clearly documented in the report; time since previous 
 audit is always implied.
>>>
>>> Again, I don't believe that it is reasonable to assume that 
>>> auditing/sampling has been done over the full year.
>>>
>> 
>> [NS]: No assumptions are made. This is common practice and common 
>> understanding.
>
>
>Sigh. If it were so well understood then I would think CAs and auditors 
>would be providing better answers regarding whether their audits are 
>point-in-time or full audits, and what the audit period start and end dates 
>are.

In the ETSI audits I've been participating (and also in nearly all other 
audits, be it ISO 27001 or ISO 9001) the auditor was differentiating between a 
Test of Design (ToD) and Test of Effectiveness (ToE) for every control. For the 
ToD the auditor looks at the very moment of the audit into the processes or 
technical methods that are in place to fulfill the requirements of the specific 
control. He assesses if those methods or processes seem to be sound and 
reasonable by his professional experience or other standards. For the ToE the 
auditor takes evidence from the audit period in the past to check, first, if 
the auditee always followed the methods or processes checked in the ToD and, 
second, if the methods and processes really worked to fulfill the goal of the 
control. Failures in the tests are documented in the audit report. The 
certificate is only issued if there were no significant deviations found.

My question to the WebTrust community would be, if the WebTrust auditors work 
significantly different? And if yes, what are the differences?

>Sorry if I'm being slow here, but how do we get the ETSI audits and audit 
>statements fixed ASAP?

Microsoft has published a form (http://aka.ms/rootcertapply) that needs to be 
filled in after every audit by the auditor with all additional information 
required by Microsoft beyond the normal audit certificate. This form is 
collected by Microsoft from the Root CAs and by the Root CA from their Issuing 
CAs. Maybe introducing such a form for Mozilla as well could be a low hanging 
fruit to increase audit documentation quality.

Further more you could publish the names of the auditors or the auditing 
companies that fail to comply with your requirements. If there is a cluster of 
auditors / companies that often fail to comply those would practically be 
disqualified for further audits since nobody with a straight mind would hire 
such an auditor / audit company again.


With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com

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

Third party use of OneCRL

[niklas.bachmaier--- via dev-security-policy]

Hi all

I'm working for a big managed security provider. We would like to benefit from 
OneCRL as a means of improving our certificate revocation checking. 

I could download OneCRL at 
https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records.
 My question is if there is a license on OneCRL or if we are free to use it? 
Further I'm wondering if Mozilla has already thought about third party users 
and provides another way of getting the most recent version of OneCRL than 
getting the above mentioned website and comparing if the content has changed?

Thanks a lot already for any feedback on this!

Niklas
___
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

[Moudrick M. Dadashov via dev-security-policy]

Thank you for clarification.

Do you think the terms "/approval scheme/", "/supervision scheme/", 
"/accreditation//scheme/" etc. (used in some ETSI TSs or the Commission 
Decisions) have the same meaning and ETSI EN 319 403 is just one of 
possible "/certification scheme/s"?


Thanks,
M.D.

On 11/6/2017 6:05 PM, m.wiedenhorst--- via dev-security-policy wrote:

TÜViT as a conformity assessment body would like to add some explanations to 
clear up some misunderstandings about ETSI auditing.
First of all, we would like to give one preliminary remark. ETSI has separated 
the TSP technical requirements (ETSI EN 319 411-1, ETSI EN 319 401) from the 
CAB auditing requirements (ETSI EN 319 403). This is an ISO international 
standardization best practice (principle 1 of ISO / IEC 17007) not to mix 
technical requirements (“what to audit”) with auditing requirements (“how to 
perform such audits”).

Given that, the main issue of this thread seems to be the question about the 
point-in-time vs. period-of-time audit approach.
Of course, every properly conducted audit has to include and examine the 
point-in-time situation at the time of the current audit. But beyond that, every 
properly conducted audit must cover the operations performed since the last audit. 
The latter is defined by ETSI EN 319 403. In its section 7.9 it deals with 
surveillance and re-assessment. It has already been agreed upon without objections 
(during the CABF F2F Bilbao meeting, if we remember correctly) that only annual 
full system audits are eligible in the context of CABF BR and/or EVG. As a 
consequence, every audit (aside from the very first initial audit => 
point-in-time / pre-issuance readiness assessment) must be performed as 
re-assessment and the relaxations for surveillance audits introduced in this 
section do not apply in the BR / EVG context. In its last sentence this section 
declares, that auditors must cover a sample of records on the operations performed 
since the previous audit.
It is our firm opinion, shared by our national accreditation body, that this 
defines an audit period ranging from the date of the last audit up to the date 
of the current audit and that the complete period needs to be examined, not 
only certain bits and pieces of it. However, if the current phrase is causing 
problems, we are absolutely willing to approach ETSI in order to request an 
explicit clarification of this in a future version of the standard.
As you correctly pointed out, the ETSI EN 319 403 in section 7.10 includes a 
notification scheme, where the CA’s are required to notify changes affecting 
the certification to the conformity assessment body. But as stated above, this 
is not a replacement for the backward-looking period-of-time audit approach. It 
is a supplement in order to perform auditing of security-relevant changes (and 
identify changes that would be non-conformant!) in a timely manner and not only 
at the next annual full audit.
Summarizing this, a properly conducted ETSI audit includes both point-in-time 
and period-of-time (and the latter both backward- as well as forward-).

Another issue obviously is the proper format of a publicly facing audit report 
/ audit attestation to be presented to the root programs.
With this we are totally on your side, an acceptable report / attestation must 
clearly state the required facts in order to enable to deal with it. These 
reports are not and cannot be completely defined in the ETSI EN 319 403 
standard, as different use cases (“consumers”) might require different sets of 
information.
However, in our opinion the CABF and browser root programs give sufficient 
information about the required contents. We are willing to readopt the idea of 
creating a mandatory template for such audit attestation. This idea had been in 
the field since some CABF F2F-Meetings but obviously has never been finalized. 
Root programs could then simply decline all attestations that do not conform to 
the template.
We are open to further discussions, e.g. at the next CA-Day 
(https://www.tuvit.de/en/news/events/events-detail/details/9-ca-day-2017/) or 
at any upcoming CABF F2F meeting.

Best regards
Matthias Wiedenhorst, TÜViT
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

Re: Incident Report : GlobalSign certificates with ROCA Fingerprint

[Gervase Markham via dev-security-policy]

On 03/11/17 18:16, douglas.beat...@gmail.com wrote:
> Here is the final incident report

Thanks, Doug :-)

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

[m.wiedenhorst--- via dev-security-policy]

TÜViT as a conformity assessment body would like to add some explanations to 
clear up some misunderstandings about ETSI auditing.
First of all, we would like to give one preliminary remark. ETSI has separated 
the TSP technical requirements (ETSI EN 319 411-1, ETSI EN 319 401) from the 
CAB auditing requirements (ETSI EN 319 403). This is an ISO international 
standardization best practice (principle 1 of ISO / IEC 17007) not to mix 
technical requirements (“what to audit”) with auditing requirements (“how to 
perform such audits”). 

Given that, the main issue of this thread seems to be the question about the 
point-in-time vs. period-of-time audit approach. 
Of course, every properly conducted audit has to include and examine the 
point-in-time situation at the time of the current audit. But beyond that, 
every properly conducted audit must cover the operations performed since the 
last audit. The latter is defined by ETSI EN 319 403. In its section 7.9 it 
deals with surveillance and re-assessment. It has already been agreed upon 
without objections (during the CABF F2F Bilbao meeting, if we remember 
correctly) that only annual full system audits are eligible in the context of 
CABF BR and/or EVG. As a consequence, every audit (aside from the very first 
initial audit => point-in-time / pre-issuance readiness assessment) must be 
performed as re-assessment and the relaxations for surveillance audits 
introduced in this section do not apply in the BR / EVG context. In its last 
sentence this section declares, that auditors must cover a sample of records on 
the operations performed since the previous audit.
It is our firm opinion, shared by our national accreditation body, that this 
defines an audit period ranging from the date of the last audit up to the date 
of the current audit and that the complete period needs to be examined, not 
only certain bits and pieces of it. However, if the current phrase is causing 
problems, we are absolutely willing to approach ETSI in order to request an 
explicit clarification of this in a future version of the standard.
As you correctly pointed out, the ETSI EN 319 403 in section 7.10 includes a 
notification scheme, where the CA’s are required to notify changes affecting 
the certification to the conformity assessment body. But as stated above, this 
is not a replacement for the backward-looking period-of-time audit approach. It 
is a supplement in order to perform auditing of security-relevant changes (and 
identify changes that would be non-conformant!) in a timely manner and not only 
at the next annual full audit.
Summarizing this, a properly conducted ETSI audit includes both point-in-time 
and period-of-time (and the latter both backward- as well as forward-).

Another issue obviously is the proper format of a publicly facing audit report 
/ audit attestation to be presented to the root programs. 
With this we are totally on your side, an acceptable report / attestation must 
clearly state the required facts in order to enable to deal with it. These 
reports are not and cannot be completely defined in the ETSI EN 319 403 
standard, as different use cases (“consumers”) might require different sets of 
information. 
However, in our opinion the CABF and browser root programs give sufficient 
information about the required contents. We are willing to readopt the idea of 
creating a mandatory template for such audit attestation. This idea had been in 
the field since some CABF F2F-Meetings but obviously has never been finalized. 
Root programs could then simply decline all attestations that do not conform to 
the template.
We are open to further discussions, e.g. at the next CA-Day 
(https://www.tuvit.de/en/news/events/events-detail/details/9-ca-day-2017/) or 
at any upcoming CABF F2F meeting.

Best regards
Matthias Wiedenhorst, TÜViT
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy