Re: Verifying Auditor Qualifications

[Kathleen Wilson via dev-security-policy]

On 6/4/20 1:25 AM, Arvid Vermote wrote:

Hi Kathleen

Related to the below it would be helpful if the WebTrust organization would 
disclose additional details on the licensed WebTrust practitioners: right now 
there is no data publicly available on historical WebTrust auditor licensing. 
We don't know as of when an auditor has been licensed and as far as I am aware 
there is no overview of auditors that did not renew, withdrew or had their 
license revoked. Having such a list would certainly help CAs in the auditor 
selection process and better monitoring of auditor qualifications.

The Dutch NAB has an excellent inventory of their suspensions and withdrawals 
of accreditations: 
https://www.rva.nl/en/accredited-organisations/suspended-withdrawals. We think 
everyone would benefit from the WebTrust task force / CPA Canada maintaining a 
similar public inventory.

Thanks

Arvid



Hi Arvid,

Your message has been forwarded to WebTrust and CPA Canada folks.

Thanks,
Kathleen

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

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Kathleen Wilson via dev-security-policy]

On 6/4/20 11:17 AM, Ben Wilson wrote:

Having received no further comments, I have recommended approval of this
request in bug 1445364


- Ben




To clarify, Ben is recommending approval of the request to include the 
e-Szigno Root CA 2017 certificate and enable the websites trust bit.


However, he has recommended that we deny the request for EV treatment 
for both root certificates. Microsec may re-apply by filing a new 
request for EV treatment after they have demonstrated improved 
compliance with the BRs and EV Guidelines.


Reference: 
https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/yLTkQ25uAAAJ


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

Re: Request to Include certSIGN Root CA G2 certificate

[Ben Wilson via dev-security-policy]

Having received no further comments, I have recommended approval of this
request in bug 1403453


- Ben

On Thu, May 28, 2020 at 12:06 PM Ben Wilson  wrote:

> In accordance with the CA inclusion process[1], this is a summary of the
> public discussion of Certsign’s application for inclusion of the certSIGN
> ROOT CA G2 into the Mozilla root store with the websites trust bit and EV
> enabled. The request is documented in Bugzilla #1403453[2]. The public
> discussion began on 6-May-2020[3].
>
> During the public discussion, it was noted that the audit report listed
> six minor non-conformities regarding documentation and process
> implementation[4]. Of primary concern was recordkeeping of the CA key
> shares. Certsign responded that all six non-conformities, including key
> share recordkeeping, had been remediated[5]. Specifically with regard to
> the CA key shares, Certsign has registered its DR backup shares in its
> asset inventory, card custody is recorded, use of secrets by the
> application is logged by a script, and person(s) with access to the
> safeboxes no longer has/have access to the room where the safeboxes are
> stored.[6]
>
> No other comments were received.
>
> Based on a totality of the information presented and reviewed, I am
> planning to recommend that Certsign’s application be approved.
>
>
> I appreciate any feedback on this proposed course of action.
>
> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1403453
>
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/rJke0W6eAwAJ
>
>
> [4] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635
>
> [5] https://bugzilla.mozilla.org/attachment.cgi?id=9149366
>
> [6]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/ynPfdYtz0Ag/Nfbq64TyBwAJ
>
>
> On Wed, May 13, 2020 at 3:18 AM Gabriel Petcu via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On Saturday, May 9, 2020 at 12:56:00 AM UTC+3, Wayne Thayer wrote:
>> > The ETSI audit attestation statement referenced by Ben [1] lists 6
>> > non-conformities that were to be corrected within 3 months of the onsite
>> > audit that occurred on 2020-02-10 until 2020-02-14:
>> >
>> > Findings with regard to ETSI EN 319 401:
>> > -REQ-7.8-06–Documentation shall be improved
>> >
>> > Findings with regard to ETSI EN 319 411-1:
>> > -REG-6.3.1-01–Implementation shall be improved
>> > -GEN-6.5.1-04-Implementation shall be improved
>> >
>> > Findings with regard to ETSI EN 319 411-2:
>> > -SDP-6.5.1-02 -Implementation shall be improved
>> > -GEN-6.6.1-05–Documentation shall be improved
>> > -CSS-6.3.10-13–Documentation shall be improved
>> >
>> > I'm particularly concerned about GEN-6.5.1-04: The CA key pair used for
>> > signing certificates shall be created under, at least, dual control.
>> >
>> > I'd like to see an explanation of these non-conformities and the
>> > remediation from certSIGN, and confirmation from LSTI that they have
>> been
>> > fixed.
>> >
>> > - Wayne
>> >
>> > [1] https://bug1632406.bmoattachments.org/attachment.cgi?id=9142635
>> >
>> > On Wed, May 6, 2020 at 4:59 PM Ben Wilson via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> > > This request is for inclusion of the certSIGN Root CA G2 certificate
>> and to
>> > > turn on the Websites trust bit and for EV treatment.
>> > >
>> > >
>> > > The request is documented in Bugzilla and in the CCADB as follows:
>> > >
>> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1403453
>> > >
>> > >
>> > >
>> https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0403
>> > >
>> > > (Summary of info gathered and verified, URLs for test websites, etc.)
>> > >
>> > >
>> > >
>> > > * certSIGN’s BR Self Assessment is here:
>> > >
>> > > https://bugzilla.mozilla.org/attachment.cgi?id=9052673
>> > >
>> > > The Certsign document repository can be found here:
>> > >
>> > > https://www.certsign.ro/en/certsign-documents/policies-procedures
>> > >
>> > > * Root Certificate Locations:
>> > >
>> > > http://crl.certsign.ro/certsign-rootg2.crt
>> > >
>> > > http://registru.certsign.ro/certcrl/certsign-rootg2.crt
>> > >
>> > > http://www.certsign.ro/certcrl/certsign-rootg2.crt
>> > >
>> > >
>> > >
>> https://crt.sh/?q=657CFE2FA73FAA38462571F332A2363A46FCE7020951710702CDFBB6EEDA3305
>> > >
>> > >
>> > >
>> https://censys.io/certificates/657cfe2fa73faa38462571f332a2363a46fce7020951710702cdfbb6eeda3305/pem
>> > >
>> > >
>> > > * EV Policy OID:   2.23.140.1.1
>> > >
>> > > * CRL URL: http://crl.certsign.ro/certsign-rootg2.crl
>> > >
>> > > * OCSP URL: http://ocsp.certsign.ro
>> > >
>> > >
>> > >
>> > > * Audit: See https://bugzilla.mozilla.org/attachment.cgi?id=9142635 (
>> > >
>> > >
>> http://lsti-certification.fr/images/LSTI_Audit_Atttestation_Letter_1612-163_V10_Certsign_S.pdf
>> > > )
>> > > which shows that a 

Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009

[Ben Wilson via dev-security-policy]

Having received no further comments, I have recommended approval of this
request in bug 1445364


- Ben

On Tue, Jun 2, 2020 at 1:57 PM Ben Wilson  wrote:

> I have now reviewed Microsec's updated CPS for OV and DV.  I am not going
> to hold up approval of the inclusion of this root for the following
> reasons, which I believe are relatively minor, but Microsec should be aware
> that:
>
>- section 3.1.1 of Microsec's "eIDAS conform Certificate for Website
>Authentication CPS" (
>https://static.e-szigno.hu/docs/szsz--fok--ssl--EN--v2.14.pdf) ("the
>CPS") appears to allow certain identifiers, allowed for EV, but not yet
>added to the Baseline Requirements, see
>
> https://cabforum.org/2019/05/21/ballot-sc17-version-7-alternative-registration-numbers-for-ev-certificates/.
>This is something that should be taken up with the CA/Browser Forum (and
>corrected in Microsec's CPS); and
>- section 4.9.5 of the CPS, which states, "Emails arriving out of
>office hours are considered as arrived at the beginning of the next
>business day." This may put Microsec at risk of a violation of the Baseline
>Requirements sections 4.9.1 through 4.9.5. While "receipt" (or "arrival")
>is not yet defined in the Baseline Requirements, there is an expectation of
>24x7 availability, which it appears Microsec is providing - "The Trust
>Service Provider maintains a continuous 24x7 ability to respond internally
>to a High Piority Certificate Problem Report."
>
> This concludes my review of the Microsec CPs/CPSes, and I believe it is
> now appropriate to begin the process of adding this root CA into NSS
> (without EV enablement).
>
> On Thu, May 28, 2020 at 1:00 PM Ben Wilson  wrote:
>
>> In accordance with the CA inclusion process,[1] this is a summary of the
>> public discussion of Microsec’s application for inclusion of the e-Szigno
>> Root CA 2017 into the Mozilla root store, and to EV enable it and the
>> currently-included e-Szigno Root CA 2009. The request is documented in
>> Bugzilla #1445364.[2] The public discussion began on 9-March-2020.[3] The
>> email launching the public discussion and comments received during the
>> public discussion raised a number of issues, not all of which are itemized
>> here, including:
>>
>> * the CPS was unclear about certificate problem reporting and revocation
>> request processing[4]; and
>>
>> * Microsec has had systemic, standards-related non-conformities, e.g.
>> Bug# 1622539[5], and needs to demonstrate better behavior in keeping up
>> with and complying with the CABF Baseline Requirements and root store
>> policy.[6]
>>
>> Microsec is resolving these concerns by:
>>
>> - updating its CPS[7][8]; and
>>
>> - committing to engage in better compliance with industry standards[9].
>>
>> In my opinion Microsec has demonstrated sufficient response that we do
>> not need to remove Microsec from Mozilla’s root store. Therefore, once I am
>> satisfied after a review of the updated CPS, I am planning to recommend
>> that we approve the request to include the e-Szigno Root CA 2017
>> certificate and enable the websites trust bit. However, I plan to deny
>> the request for EV treatment for both root certificates. Microsec may
>> re-apply by filing a new request for EV treatment after they have
>> demonstrated improved compliance with the BRs and EV Guidelines.
>>
>> I appreciate any feedback on this proposed course of action.
>>
>> [1] https://wiki.mozilla.org/CA/Application_Process#Process_Overview
>>
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1445364
>>
>> [3]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/QrhdAWq_AAAJ
>>
>> [4]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/KN-gnSLLAAAJ
>>
>>
>> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1622539
>>
>> [6]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/T7hcaOYGAQAJ
>>
>>
>> [7]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/rHTmKOzspCo/pyZKc40_CQAJ
>>
>>
>> [8]
>> https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/1L0crAafm30
>>
>>
>> [9]
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/jRKOr4nvOfY/mNFZGgXBAgAJ
>>
>>
>>
>> On Mon, Apr 20, 2020 at 5:44 AM Sándor dr. Szőke via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>>
>>> Dear Ben,
>>>
>>> I confirm that Microsec will correct all issues in the CP and CPS
>>> documents as promised during the public discussion.
>>>
>>> Thanks to everyone who took the time to read Microsec CP and CPS and to
>>> comment on them.
>>>
>>> If there are no more comments on the content of our CP and CPS documents
>>> in the public discussion, we will review the thread again and gather all
>>> the issues to be resolved.
>>> As usual, Microsec will review current versions of all applicable
>>> requirements for changes.
>>>
>>> I confirm 

CA Configuration and Operation

[Ben Wilson via dev-security-policy]

Often CA configurations and settings are complex and can be difficult to
manage. We would like to remind CA operators that they need to be familiar
with the configuration and operation of all aspects of CA software and
ensure that they have adequate documentation and training.

For example, in April, a CA operator in the Mozilla Root Program received a
post-issuance warning that a certificate with an RSASSA-PSS key had made it
through the EJBCA pre-issuance check.[1][2]  Apparently, “Check for RSA” on
CSR input allowed an RSASSA-PSS key through because it was considered part
of the RSA suite that was whitelisted. Internal documentation for CA setup
did not include correct validator (pre-issuance) configuration setup.

The CA operator started an investigation into why this occurred. Upon
investigation the CA operator discovered that the validator had started
functioning due to a configuration change occurring unbeknownst to an
engineer when he clicked on save after selecting the validator in CA
settings. The CA operator explained that highlighting the specific
validator was an additional required step after adding a certificate
profile in the validator settings. This additional step was not clearly
stated in the CA software manual.

The vendor has explained that this misunderstanding was due to the fact
that validators need to be enabled on a certificate-profile basis, in order
to allow the same CA to host multiple profiles without validators
conflicting with each other. As certificate profiles can be shared amongst
multiple CAs, the validator needs to be selected there as well.

The vendor also recommends that CA operators use the provided human
readable configuration export tool to run and diff after upgrades and
configuration changes to verify that nothing unintended has changed.

In summary, the general purpose of this email is to urge all CA operators
to be familiar with configuration processes of the CA software that they
use, and specifically to alert users of EJBCA to the procedural measures
described above.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1630870

[2] EJBCA software by Primekey has a pre-issuance “validator” system for
keys, amongst which an external validator to run linters. See
https://doc.primekey.com/ejbca/ejbca-operations/ejbca-ca-concept-guide/validators-overview/post-processing-validators
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Verifying Auditor Qualifications

[Arvid Vermote via dev-security-policy]

Hi Kathleen

Related to the below it would be helpful if the WebTrust organization would 
disclose additional details on the licensed WebTrust practitioners: right now 
there is no data publicly available on historical WebTrust auditor licensing. 
We don't know as of when an auditor has been licensed and as far as I am aware 
there is no overview of auditors that did not renew, withdrew or had their 
license revoked. Having such a list would certainly help CAs in the auditor 
selection process and better monitoring of auditor qualifications. 

The Dutch NAB has an excellent inventory of their suspensions and withdrawals 
of accreditations: 
https://www.rva.nl/en/accredited-organisations/suspended-withdrawals. We think 
everyone would benefit from the WebTrust task force / CPA Canada maintaining a 
similar public inventory.

Thanks

Arvid

> -Original Message-
> From: dev-security-policy  On
> Behalf Of Kathleen Wilson via dev-security-policy
> Sent: donderdag 4 juni 2020 1:21
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Verifying Auditor Qualifications
> 
> All,
> 
> It recently came to my attention that I need to be more diligent in verifying 
> auditor
> qualifications. Therefore, we have added a field in the CCADB called “Date
> Qualifications Verified” (on Auditor Location objects), which will be used to 
> remind
> root store operators to check each auditor’s qualifications every year. This 
> field
> can only be edited by a root store operator, and we will enter this date 
> whenever
> we confirm that the auditor is still qualified to perform ETSI or WebTrust 
> audits.
> 
> Some of you may notice that your Audit Case or Root Inclusion Case has the
> message: “Auditor Verification Date is blank”. This warning message is 
> intended
> to remind root store operators that we need to verify the auditor's 
> qualifications. In
> the future you may also notice a warning message when the date in that field 
> is
> over a year old, reminding us root store operators to re-verify the auditor's
> qualifications.
> 
> I will greatly appreciate your input on the following new wiki page section,
> especially in regards to verifying auditor qualifications.
> 
> https://wiki.mozilla.org/CA/Audit_Statements#Auditor_Qualifications
> 
> Thanks,
> Kathleen
> ___
> 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