Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Audit requirements
599 views
Skip to first unread message
Peter Bowen
Sep 22, 2016, 6:57:26 PM9/22/16
to dev-secur...@lists.mozilla.org
Kathleen, Gerv, Richard and m.d.s.p,
In reviewing the WebTrust audit documentation submitted by various CA
program members and organizations wishing to be members, it seems
there is possibly some confusion on what is required by Mozilla. I
suspect this might also span to ETSI audit documentation, but I don't
know the ETSI process as well, so will leave it to some else to
determine if there is confusion there.
The first part of the confusion comes from the scope of the audit.
When engaging an auditor to provide attestion services, it is up to
the organization to define the scope of the audit. For audits
utilizing the WebTrust criteria, the scope could be all parts of the
criteria. According to auditors I have spoken with, the report will
indicate which portions of the criteria were in scope for the audit by
including a statement of items in scope on the management assertion.
If the assertion does not include an item, or the auditor does not
express an opinion about the item, then it should be assumed to be out
of scope.
I have seen a number of reports that do not include all of the
criteria be in scope. Specifically, many reports do not provide an
opinion on criteria 7 ("Subordinate CA Certificate Life Cycle
Management") of the Trust Services and Principles and Criteria for
Certification Authorities. Given the emphasis on subordinate CAs in
the Mozilla policy, it would seem that this should be required for any
CA which does not the zero path length constraint. The current
inclusion policy item 11 presumably includes this already, but does
not specifically state that all parts of the listed criteria must be
included.
The second item of confusion seems to be which CA certificate subjects
must be audited. A number of CAs only include the subjects of CA
certificates directly included in the Mozilla products and do not
include the subjects of subordinate CA certificates. My impression is
that there should be a report clearly covering each of subject of a
unconstrained CA certificate in the heirarchy, as described in item 8
of the inclusion policy. This includes a Baseline Requirements report
for any unconstrained CA, even if the CA is not intended to be used
for server authentication ("SSL") certificates.
What is Mozilla's expectation? Do CAs need to ensure that all
components of the criteria are included in their report and ensure
that all unconstrained subordinates are identified as being covered by
the reports?
Thanks,
Peter
In reviewing the WebTrust audit documentation submitted by various CA
program members and organizations wishing to be members, it seems
there is possibly some confusion on what is required by Mozilla. I
suspect this might also span to ETSI audit documentation, but I don't
know the ETSI process as well, so will leave it to some else to
determine if there is confusion there.
The first part of the confusion comes from the scope of the audit.
When engaging an auditor to provide attestion services, it is up to
the organization to define the scope of the audit. For audits
utilizing the WebTrust criteria, the scope could be all parts of the
criteria. According to auditors I have spoken with, the report will
indicate which portions of the criteria were in scope for the audit by
including a statement of items in scope on the management assertion.
If the assertion does not include an item, or the auditor does not
express an opinion about the item, then it should be assumed to be out
of scope.
I have seen a number of reports that do not include all of the
criteria be in scope. Specifically, many reports do not provide an
opinion on criteria 7 ("Subordinate CA Certificate Life Cycle
Management") of the Trust Services and Principles and Criteria for
Certification Authorities. Given the emphasis on subordinate CAs in
the Mozilla policy, it would seem that this should be required for any
CA which does not the zero path length constraint. The current
inclusion policy item 11 presumably includes this already, but does
not specifically state that all parts of the listed criteria must be
included.
The second item of confusion seems to be which CA certificate subjects
must be audited. A number of CAs only include the subjects of CA
certificates directly included in the Mozilla products and do not
include the subjects of subordinate CA certificates. My impression is
that there should be a report clearly covering each of subject of a
unconstrained CA certificate in the heirarchy, as described in item 8
of the inclusion policy. This includes a Baseline Requirements report
for any unconstrained CA, even if the CA is not intended to be used
for server authentication ("SSL") certificates.
What is Mozilla's expectation? Do CAs need to ensure that all
components of the criteria are included in their report and ensure
that all unconstrained subordinates are identified as being covered by
the reports?
Thanks,
Peter
Gervase Markham
Sep 23, 2016, 5:44:46 AM9/23/16
to Peter Bowen
On 22/09/16 23:57, Peter Bowen wrote:
> Kathleen, Gerv, Richard and m.d.s.p,
Hi Peter,
> Kathleen, Gerv, Richard and m.d.s.p,
These are good points. I know Kathleen and some other root program
owners have been discussing whether a document giving best practice
guidance for the authorship of audit reports might be a good thing.
These issues sound like excellent candidates to be mentioned in such a
document. There might also be value in considering some clarifications
to our policy as part of the 2.3 update round.
Gerv
Kurt Roeckx
Sep 23, 2016, 8:30:23 AM9/23/16
to mozilla-dev-s...@lists.mozilla.org
On 2016-09-23 00:57, Peter Bowen wrote:
> Kathleen, Gerv, Richard and m.d.s.p,
>
> In reviewing the WebTrust audit documentation submitted by various CA
> program members and organizations wishing to be members, it seems
> there is possibly some confusion on what is required by Mozilla. I
> suspect this might also span to ETSI audit documentation, but I don't
> know the ETSI process as well, so will leave it to some else to
> determine if there is confusion there.
So at least 1 thing I miss in those audit reports is which CAs are
> Kathleen, Gerv, Richard and m.d.s.p,
>
> In reviewing the WebTrust audit documentation submitted by various CA
> program members and organizations wishing to be members, it seems
> there is possibly some confusion on what is required by Mozilla. I
> suspect this might also span to ETSI audit documentation, but I don't
> know the ETSI process as well, so will leave it to some else to
> determine if there is confusion there.
covered. If you look at the CAs they disclosed, how can we be sure that
the audit actually covers that CA? I think the report should cover at
least all root and intermediate CAs that are required to be disclosed by
Mozilla.
Kurt
Jakob Bohm
Sep 23, 2016, 9:23:16 AM9/23/16
to mozilla-dev-s...@lists.mozilla.org
submitted). Examples would include cross-signed copies of other root
CAs (which already submit audit reports), as well as CAs covered by
submitted audit reports of other parts of the same CA organization (for
example, StartCOM might be cross-signed by WoSign but audited
separately, and the WoSign EV SubCA is audited separately under
stricter rules).
For such certificates it would be enough for the parent CA audit report
to list them and state that separate audit reports should be checked
for those (the auditor of the parent CA audit report may not know the
outcome of the the subCA audit when issuing his report on the parent
CA). Of cause the audit of the parent CA should still audit the
controls that prevent issuing SubCA certificates that are unlikely to
be compliant, regardless if those controls are "we only sign our own
in-house SubCAs using a multi-person signing ceremony" or "we sign any
SubCA that pays a fee and passes a full BR audit by Ernst, Young or
Deloite".
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
Peter Bowen
Sep 23, 2016, 11:18:29 AM9/23/16
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
On Fri, Sep 23, 2016 at 5:29 AM, Kurt Roeckx <ku...@roeckx.be> wrote:
> On 2016-09-23 00:57, Peter Bowen wrote:
>>
> On 2016-09-23 00:57, Peter Bowen wrote:
>>
>> Kathleen, Gerv, Richard and m.d.s.p,
>>
>> In reviewing the WebTrust audit documentation submitted by various CA
>> program members and organizations wishing to be members, it seems
>> there is possibly some confusion on what is required by Mozilla. I
>> suspect this might also span to ETSI audit documentation, but I don't
>> know the ETSI process as well, so will leave it to some else to
>> determine if there is confusion there.
>
>
>>
>> In reviewing the WebTrust audit documentation submitted by various CA
>> program members and organizations wishing to be members, it seems
>> there is possibly some confusion on what is required by Mozilla. I
>> suspect this might also span to ETSI audit documentation, but I don't
>> know the ETSI process as well, so will leave it to some else to
>> determine if there is confusion there.
>
>
> So at least 1 thing I miss in those audit reports is which CAs are covered.
> If you look at the CAs they disclosed, how can we be sure that the audit
> actually covers that CA? I think the report should cover at least all root
> and intermediate CAs that are required to be disclosed by Mozilla.
And many audit reports specify this. See the following examples from
> If you look at the CAs they disclosed, how can we be sure that the audit
> actually covers that CA? I think the report should cover at least all root
> and intermediate CAs that are required to be disclosed by Mozilla.
the Mozilla included CAs report. I didn't check all -- I'm sure many
more have lists of in scope CAs.
https://cert.webtrust.org/SealFile?seal=2032&file=pdf (in the first
paragraph lists the CAs)
https://cert.webtrust.org/SealFile?seal=1998&file=pdf (first paragraph
lists the CA, appendix listing the CA details)
https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA.pdf
(bulleted list of CAs)
https://cert.webtrust.org/SealFile?seal=2092&file=pdf (first paragraph)
https://cert.webtrust.org/SealFile?seal=1944&file=pdf (Appendix
listing CA details)
https://cert.webtrust.org/SealFile?seal=1568&file=pdf (Appendix listing CAs)
So for many reports you don't have to guess which are covered.
Thanks,
Peter
Peter Bowen
Sep 23, 2016, 11:32:29 AM9/23/16
to Jakob Bohm, mozilla-dev-s...@lists.mozilla.org
On Fri, Sep 23, 2016 at 6:22 AM, Jakob Bohm <jb-mo...@wisemo.com> wrote:
> On 23/09/2016 14:29, Kurt Roeckx wrote:
>>
> On 23/09/2016 14:29, Kurt Roeckx wrote:
>>
> Except those that are covered by separate Audit reports (also
> submitted). Examples would include cross-signed copies of other root
> CAs (which already submit audit reports), as well as CAs covered by
> submitted audit reports of other parts of the same CA organization (for
> example, StartCOM might be cross-signed by WoSign but audited
> separately, and the WoSign EV SubCA is audited separately under
> stricter rules).
>
> For such certificates it would be enough for the parent CA audit report
> to list them and state that separate audit reports should be checked
> for those (the auditor of the parent CA audit report may not know the
> outcome of the the subCA audit when issuing his report on the parent
> CA).
The lack of inclusion is the implication that you need to do so.
> submitted). Examples would include cross-signed copies of other root
> CAs (which already submit audit reports), as well as CAs covered by
> submitted audit reports of other parts of the same CA organization (for
> example, StartCOM might be cross-signed by WoSign but audited
> separately, and the WoSign EV SubCA is audited separately under
> stricter rules).
>
> For such certificates it would be enough for the parent CA audit report
> to list them and state that separate audit reports should be checked
> for those (the auditor of the parent CA audit report may not know the
> outcome of the the subCA audit when issuing his report on the parent
> CA).
There could be a new criteria that the CA has publicly disclosed (via
XXX?) all CA certificates it has signed, but this is not currently a
WebTrust criteria.
> Of cause the audit of the parent CA should still audit the
> controls that prevent issuing SubCA certificates that are unlikely to
> be compliant, regardless if those controls are "we only sign our own
> in-house SubCAs using a multi-person signing ceremony" or "we sign any
> SubCA that pays a fee and passes a full BR audit by Ernst, Young or
> Deloite".
of assurance of controls around issuance of subordinate CA
certificates.
Thanks,
Peter
Myers, Kenneth (10421)
Sep 27, 2016, 4:31:34 PM9/27/16
to dev-secur...@lists.mozilla.org
I think it has also been discussed of the consistency between WebTrust auditors. The WebTrust for CA use of criteria and illustrative controls may leave to much room for interpretation by an auditor. There is also the potential gap between the WebTrust licensed firm and the individual auditors which again leaves room that the firm is properly training its auditors in how to conduct/understanding of PKI operations.
The US Federal PKI has created its own criteria that relies on a direct CP-to-CPS analysis. An FPKI affiliate may use any audit standard as long as it includes an addendum that a CP-to-CPS analysis was conducted along with annual core requirements. WebTrust has recognized this additional requirement as part of their Certification Compliance Matrix.
If anyone is interested, FPKI Compliance Audit Requirements can be found here https://www.idmanagement.gov/IDM/s/article_detail?link=fpki-audit-info
NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.
The US Federal PKI has created its own criteria that relies on a direct CP-to-CPS analysis. An FPKI affiliate may use any audit standard as long as it includes an addendum that a CP-to-CPS analysis was conducted along with annual core requirements. WebTrust has recognized this additional requirement as part of their Certification Compliance Matrix.
If anyone is interested, FPKI Compliance Audit Requirements can be found here https://www.idmanagement.gov/IDM/s/article_detail?link=fpki-audit-info
NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.
Varga Viktor
Sep 29, 2016, 5:45:39 AM9/29/16
to Peter Bowen, dev-secur...@lists.mozilla.org
Dear Peter,
I am deeply in ETSI process, so I can give info some info:
Formerly the ETSIs are based on
* 102042 for CAs
* 101456 for CAs issuing qualified certificates (refernces frequently the 102042)
o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
The new version of these : (2016-02) (these are based on the 910/2014/EC regulation, which makes a common EU market.)
* 319411-1 for CAs
* 319412-2 for CAs issuing qualified certificates (refernces frequently the 319411-1)
o 319401 is referenced from them for technical requirements (technical requirements from 102042 and 101456 were ripped of into this documents)
o 319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles
o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust.
The ETSI audit checks:
* that the certificate issuance systems and environment are compliant with the technical or requirements. (against 319401)
* that the certificate profiles meet the requirements (against 319412s)
* the CP/CPS and the practice of issuance compliant with the 319411-1 (and for qualified certificates with 319411-2)
o the 319411-1 and 319411-2 defines various Certification policies, and rules for them.
LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones (qcp-n, qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)
For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, which looks like a chimera for me :) )
At the end of audit each issuing subcas are checked against the compliance with issuing policies, profiles, and technical requirements.
Of-course the ETSI report, or its Annex also includes the whole list of the subordinates too.
Also the Microsoft doesn't accepts audit report without the subordinate list, so its mandatory nowadays.
I think what is important to add the 319411-1 and -2 to the actual acceptable audit requirements, because the MS ask for this, and it older version (119411 included in the 2.3 proposal)
At october I would like to upload our new audit reports to Salesforce, which are made aganst the 319411-s.
üdvözlettel //sincerelly yours,
Viktor Varga
Netlock
chief architect
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+varga.viktor=netlo...@lists.mozilla.org] On Behalf Of Peter Bowen
Sent: Friday, September 23, 2016 12:57 AM
To: mozilla-dev-s...@lists.mozilla.org <dev-secur...@lists.mozilla.org>
Subject: Audit requirements
Kathleen, Gerv, Richard and m.d.s.p,
In reviewing the WebTrust audit documentation submitted by various CA program members and organizations wishing to be members, it seems there is possibly some confusion on what is required by Mozilla. I suspect this might also span to ETSI audit documentation, but I don't know the ETSI process as well, so will leave it to some else to determine if there is confusion there.
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
I am deeply in ETSI process, so I can give info some info:
Formerly the ETSIs are based on
* 102042 for CAs
* 101456 for CAs issuing qualified certificates (refernces frequently the 102042)
o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
The new version of these : (2016-02) (these are based on the 910/2014/EC regulation, which makes a common EU market.)
* 319411-1 for CAs
* 319412-2 for CAs issuing qualified certificates (refernces frequently the 319411-1)
o 319401 is referenced from them for technical requirements (technical requirements from 102042 and 101456 were ripped of into this documents)
o 319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles
o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust.
The ETSI audit checks:
* that the certificate issuance systems and environment are compliant with the technical or requirements. (against 319401)
* that the certificate profiles meet the requirements (against 319412s)
* the CP/CPS and the practice of issuance compliant with the 319411-1 (and for qualified certificates with 319411-2)
o the 319411-1 and 319411-2 defines various Certification policies, and rules for them.
LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones (qcp-n, qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)
For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, which looks like a chimera for me :) )
At the end of audit each issuing subcas are checked against the compliance with issuing policies, profiles, and technical requirements.
Of-course the ETSI report, or its Annex also includes the whole list of the subordinates too.
Also the Microsoft doesn't accepts audit report without the subordinate list, so its mandatory nowadays.
I think what is important to add the 319411-1 and -2 to the actual acceptable audit requirements, because the MS ask for this, and it older version (119411 included in the 2.3 proposal)
At october I would like to upload our new audit reports to Salesforce, which are made aganst the 319411-s.
üdvözlettel //sincerelly yours,
Viktor Varga
Netlock
chief architect
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+varga.viktor=netlo...@lists.mozilla.org] On Behalf Of Peter Bowen
Sent: Friday, September 23, 2016 12:57 AM
To: mozilla-dev-s...@lists.mozilla.org <dev-secur...@lists.mozilla.org>
Subject: Audit requirements
Kathleen, Gerv, Richard and m.d.s.p,
In reviewing the WebTrust audit documentation submitted by various CA program members and organizations wishing to be members, it seems there is possibly some confusion on what is required by Mozilla. I suspect this might also span to ETSI audit documentation, but I don't know the ETSI process as well, so will leave it to some else to determine if there is confusion there.
The first part of the confusion comes from the scope of the audit.
When engaging an auditor to provide attestion services, it is up to the organization to define the scope of the audit. For audits utilizing the WebTrust criteria, the scope could be all parts of the criteria. According to auditors I have spoken with, the report will indicate which portions of the criteria were in scope for the audit by including a statement of items in scope on the management assertion.
If the assertion does not include an item, or the auditor does not express an opinion about the item, then it should be assumed to be out of scope.
I have seen a number of reports that do not include all of the criteria be in scope. Specifically, many reports do not provide an opinion on criteria 7 ("Subordinate CA Certificate Life Cycle
Management") of the Trust Services and Principles and Criteria for Certification Authorities. Given the emphasis on subordinate CAs in the Mozilla policy, it would seem that this should be required for any CA which does not the zero path length constraint. The current inclusion policy item 11 presumably includes this already, but does not specifically state that all parts of the listed criteria must be included.
The second item of confusion seems to be which CA certificate subjects must be audited. A number of CAs only include the subjects of CA certificates directly included in the Mozilla products and do not include the subjects of subordinate CA certificates. My impression is that there should be a report clearly covering each of subject of a unconstrained CA certificate in the heirarchy, as described in item 8 of the inclusion policy. This includes a Baseline Requirements report for any unconstrained CA, even if the CA is not intended to be used for server authentication ("SSL") certificates.
What is Mozilla's expectation? Do CAs need to ensure that all components of the criteria are included in their report and ensure that all unconstrained subordinates are identified as being covered by the reports?
Thanks,
Peter
_______________________________________________
When engaging an auditor to provide attestion services, it is up to the organization to define the scope of the audit. For audits utilizing the WebTrust criteria, the scope could be all parts of the criteria. According to auditors I have spoken with, the report will indicate which portions of the criteria were in scope for the audit by including a statement of items in scope on the management assertion.
If the assertion does not include an item, or the auditor does not express an opinion about the item, then it should be assumed to be out of scope.
I have seen a number of reports that do not include all of the criteria be in scope. Specifically, many reports do not provide an opinion on criteria 7 ("Subordinate CA Certificate Life Cycle
Management") of the Trust Services and Principles and Criteria for Certification Authorities. Given the emphasis on subordinate CAs in the Mozilla policy, it would seem that this should be required for any CA which does not the zero path length constraint. The current inclusion policy item 11 presumably includes this already, but does not specifically state that all parts of the listed criteria must be included.
The second item of confusion seems to be which CA certificate subjects must be audited. A number of CAs only include the subjects of CA certificates directly included in the Mozilla products and do not include the subjects of subordinate CA certificates. My impression is that there should be a report clearly covering each of subject of a unconstrained CA certificate in the heirarchy, as described in item 8 of the inclusion policy. This includes a Baseline Requirements report for any unconstrained CA, even if the CA is not intended to be used for server authentication ("SSL") certificates.
What is Mozilla's expectation? Do CAs need to ensure that all components of the criteria are included in their report and ensure that all unconstrained subordinates are identified as being covered by the reports?
Thanks,
Peter
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy
Erwann Abalea
Sep 29, 2016, 9:13:59 AM9/29/16
to mozilla-dev-s...@lists.mozilla.org
Bonjour,
Le jeudi 29 septembre 2016 11:45:39 UTC+2, Varga Viktor a écrit :
> Dear Peter,
>
> I am deeply in ETSI process, so I can give info some info:
>
> Formerly the ETSIs are based on
>
> * 102042 for CAs
> * 101456 for CAs issuing qualified certificates (refernces frequently the 102042)
>
> o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
>
> The new version of these : (2016-02) (these are based on the 910/2014/EC regulation, which makes a common EU market.)
>
> * 319411-1 for CAs
> * 319412-2 for CAs issuing qualified certificates (refernces frequently the 319411-1)
You meant 319411-2 here. (319412-* are certificate profiles).
> o 319401 is referenced from them for technical requirements (technical requirements from 102042 and 101456 were ripped of into this documents)
>
> o 319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles
> o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
319412-2 and 319412-3 are not used for TLS server certificates, 319412-1 is general and introduces some semantic identifiers that could be used in TLS server certs, 319412-4 is dedicated to TLS server certificates but is mostly an empty shell relying on EVG and BR, 319412-5 adds the QCStatements extension (MUST be present for Qualified certs, MAY be present for non Qualified certs).
> For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust.
No.
> The ETSI audit checks:
>
> * that the certificate issuance systems and environment are compliant with the technical or requirements. (against 319401)
> * that the certificate profiles meet the requirements (against 319412s)
> * the CP/CPS and the practice of issuance compliant with the 319411-1 (and for qualified certificates with 319411-2)
>
> o the 319411-1 and 319411-2 defines various Certification policies, and rules for them.
>
> LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones (qcp-n, qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)
>
> For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, which looks like a chimera for me :) )
>
> At the end of audit each issuing subcas are checked against the compliance with issuing policies, profiles, and technical requirements.
>
> Of-course the ETSI report, or its Annex also includes the whole list of the subordinates too.
>
> Also the Microsoft doesn't accepts audit report without the subordinate list, so its mandatory nowadays.
>
> I think what is important to add the 319411-1 and -2 to the actual acceptable audit requirements, because the MS ask for this, and it older version (119411 included in the 2.3 proposal)
My view is that 319411-2 may be an acceptable audit requirements, but since QCP-w certificates (the chimera) are not easily compared to EV certificates (because the "Qualified" attribute is granted by a supervisory body to a TSP established on its territory only), it's useless to add 319411-2 as acceptable (a CA will necessarily be 319411-1).
Le jeudi 29 septembre 2016 11:45:39 UTC+2, Varga Viktor a écrit :
> Dear Peter,
>
> I am deeply in ETSI process, so I can give info some info:
>
> Formerly the ETSIs are based on
>
> * 102042 for CAs
> * 101456 for CAs issuing qualified certificates (refernces frequently the 102042)
>
> o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
>
> The new version of these : (2016-02) (these are based on the 910/2014/EC regulation, which makes a common EU market.)
>
> * 319411-1 for CAs
> * 319412-2 for CAs issuing qualified certificates (refernces frequently the 319411-1)
> o 319401 is referenced from them for technical requirements (technical requirements from 102042 and 101456 were ripped of into this documents)
>
> o 319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles
> o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
> For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust.
> The ETSI audit checks:
>
> * that the certificate issuance systems and environment are compliant with the technical or requirements. (against 319401)
> * that the certificate profiles meet the requirements (against 319412s)
> * the CP/CPS and the practice of issuance compliant with the 319411-1 (and for qualified certificates with 319411-2)
>
> o the 319411-1 and 319411-2 defines various Certification policies, and rules for them.
>
> LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones (qcp-n, qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)
>
> For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, which looks like a chimera for me :) )
>
> At the end of audit each issuing subcas are checked against the compliance with issuing policies, profiles, and technical requirements.
>
> Of-course the ETSI report, or its Annex also includes the whole list of the subordinates too.
>
> Also the Microsoft doesn't accepts audit report without the subordinate list, so its mandatory nowadays.
>
> I think what is important to add the 319411-1 and -2 to the actual acceptable audit requirements, because the MS ask for this, and it older version (119411 included in the 2.3 proposal)
Varga Viktor
Oct 4, 2016, 5:18:28 AM10/4/16
to Erwann Abalea, mozilla-dev-s...@lists.mozilla.org
Dear Erwann,
My answers inline marked with ***
Le jeudi 29 septembre 2016 11:45:39 UTC+2, Varga Viktor a écrit :
> o 319401 is referenced from them for technical requirements (technical requirements from 102042 and 101456 were ripped of into this documents)
>
> o 319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles
> o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
*** I accept your correction. I correct myself.
I remember I read it somewhere, but can't find my source again.
(Maybe I read it in a work version left on the net.)
> The ETSI audit checks:
>
> * that the certificate issuance systems and environment are compliant with the technical or requirements. (against 319401)
> * that the certificate profiles meet the requirements (against 319412s)
> * the CP/CPS and the practice of issuance compliant with the 319411-1 (and for qualified certificates with 319411-2)
>
> o the 319411-1 and 319411-2 defines various Certification policies, and rules for them.
>
> LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones (qcp-n, qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)
>
> For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, which looks like a chimera for me :) )
>
> At the end of audit each issuing subcas are checked against the compliance with issuing policies, profiles, and technical requirements.
>
> Of-course the ETSI report, or its Annex also includes the whole list of the subordinates too.
>
> Also the Microsoft doesn't accepts audit report without the subordinate list, so its mandatory nowadays.
>
> I think what is important to add the 319411-1 and -2 to the actual acceptable audit requirements, because the MS ask for this, and it older version (119411 included in the 2.3 proposal)
Regards, Viktor Varga
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
My answers inline marked with ***
Le jeudi 29 septembre 2016 11:45:39 UTC+2, Varga Viktor a écrit :
> Dear Peter,
>
> I am deeply in ETSI process, so I can give info some info:
>
> Formerly the ETSIs are based on
>
> * 102042 for CAs
> * 101456 for CAs issuing qualified certificates (refernces frequently the 102042)
>
> o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
>
> The new version of these : (2016-02) (these are based on the 910/2014/EC regulation, which makes a common EU market.)
>
> * 319411-1 for CAs
> * 319412-2 for CAs issuing qualified certificates (refernces frequently the 319411-1)
>
> I am deeply in ETSI process, so I can give info some info:
>
> Formerly the ETSIs are based on
>
> * 102042 for CAs
> * 101456 for CAs issuing qualified certificates (refernces frequently the 102042)
>
> o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
>
> The new version of these : (2016-02) (these are based on the 910/2014/EC regulation, which makes a common EU market.)
>
> * 319411-1 for CAs
> * 319412-2 for CAs issuing qualified certificates (refernces frequently the 319411-1)
You meant 319411-2 here. (319412-* are certificate profiles).
*** You have right, it was misstyped.
> o 319401 is referenced from them for technical requirements (technical requirements from 102042 and 101456 were ripped of into this documents)
>
> o 319412-1 ,-2, -3, -4, -5 referenced from them for certificate profiles
> o BRG and EV is referenced from them for SSL and EV SSL certificate issuance.
319412-2 and 319412-3 are not used for TLS server certificates, 319412-1 is general and introduces some semantic identifiers that could be used in TLS server certs, 319412-4 is dedicated to TLS server certificates but is mostly an empty shell relying on EVG and BR, 319412-5 adds the QCStatements extension (MUST be present for Qualified certs, MAY be present for non Qualified certs).
> For EU CAs the Microsoft forces to move to ETSI audit instead Webtrust.
No.
*** I accept your correction. I correct myself.
I remember I read it somewhere, but can't find my source again.
(Maybe I read it in a work version left on the net.)
> The ETSI audit checks:
>
> * that the certificate issuance systems and environment are compliant with the technical or requirements. (against 319401)
> * that the certificate profiles meet the requirements (against 319412s)
> * the CP/CPS and the practice of issuance compliant with the 319411-1 (and for qualified certificates with 319411-2)
>
> o the 319411-1 and 319411-2 defines various Certification policies, and rules for them.
>
> LCP, NCP, NCP+, DVCP, IVCP, OVCP, EVCP, and also the new qualified ones (qcp-n, qpc-l, qcp-n-qscd, qcp-l-qscd, qcp-w)
>
> For DVCP, OVCP, IVCP, OVCP they references BRG and EVGL (and also for qcp-w, which looks like a chimera for me :) )
>
> At the end of audit each issuing subcas are checked against the compliance with issuing policies, profiles, and technical requirements.
>
> Of-course the ETSI report, or its Annex also includes the whole list of the subordinates too.
>
> Also the Microsoft doesn't accepts audit report without the subordinate list, so its mandatory nowadays.
>
> I think what is important to add the 319411-1 and -2 to the actual acceptable audit requirements, because the MS ask for this, and it older version (119411 included in the 2.3 proposal)
My view is that 319411-2 may be an acceptable audit requirements, but since QCP-w certificates (the chimera) are not easily compared to EV certificates (because the "Qualified" attribute is granted by a supervisory body to a TSP established on its territory only), it's useless to add 319411-2 as acceptable (a CA will necessarily be 319411-1).
*** It's also a possible solution to left the 411-2 out, because 411-1 covers also the LCP, NCP, NCP+ signer and ecnryption certificates too, so SMIME usage is also covered. What I just want to recommend to add also the new numbers to the current Mozilla Policy.
Regards, Viktor Varga
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
0 new messages