Re: SSL.com root inclusion request

[Andrew R. Whalley via dev-security-policy]

Greetings,

I have reviewed SSLcom_CP_CPS_Version_1_2_1 and made the following notes:

1.3.

CA diagrams are useful, thanks.

1.3.2

"SSL.com may delegate the performance of *all or any* part of these
requirements to a Delegated Third Party" though the BRs preclude sections
3.2.2.4 and 3.2.2.5. - See ballot 215 which hopes to clear up any confusion
on this topic.

1.3.2.1

"may contractually authorize the Subject of a specified Valid EV
Certificate to perform the RA function and authorize SSL.com to issue
additional EV Certificates at *third and higher domain levels* that are
contained within the domain of the original EV Certificate"

This assumes the number of labels in domains appearing in the Public Suffix
List, which is inadvisable.

1.5.5

SSL.com CP/CPS annual review:  Might be worth making it explicit that there
will be a CP/CPS version number bump even if there is no change, per
Mozilla Root Store Policy v 2.5 §3.3

3.2.2.4

"SSL.com shall confirm that, as of the date the Certificate issuance,
either SSL.com *or a Delegated Third Party* has validated each
Fully-Qualified Domain Name (FQDN) listed in the Certificate using at least
one of the methods listed below."

Section 1.3.2 of the BRs prohibits Delegated Third Parties from carrying
out procedures under §3.2.2.4 (even though it is allowed in this section of
the BRs) - See ballot 215 which hopes to clear up any confusion on this
topic.

3.2.4

"SSL.com does not verify information contained in the Organization Unit
(OU) field in any certificate request"

Section 7.1.4.2.1 of the BRs states: "The CA SHALL implement a process that
prevents an OU attribute from including a name, DBA, tradename, trademark,
address, location, or other text that refers to a specific natural person
or Legal Entity unless the CA has verified this information in accordance
with Section 3.2 and the Certificate also contains
subject:organizationName, , subject:givenName, subject:surname,
subject:localityName, and subject:countryName attributes, also verified in
accordance with Section 3.2.2.1."

4.9.2

"Non-Subscribers meeting one or more of the criteria given in Section 4.9.1"

It's not immediately clear what non-subscribers are referred to in in §4.9.1

7.1.2.2

"f. nameConstraints (optional)

If present, this extension should not be marked critical*."

Though it's a SHOULD, it's worth noting the BRs say "SHOULD NOT be marked
critical."

"It is forbidden for Intermediate CAs to issue end-entity Certificates
which blend the serverAuth (1.3.6.1.5.5.7.3.1), emailProtection
(1.3.6.1.5.5.7.3.2) and codeSigning (1.3.6.1.5.5.7.3.3) extended key
usages."

Good

9.12.1/2

"Minor changes (e.g. correction of grammatical, syntactical, spelling
errors) may, at SSL.com's sole discretion, be carried out without any prior
notice and without OID modification."

Even if the version number isn't changed, it would be good to ensure all
modifications, however minor, are listed in the Version Control table of
§1.2.1

--

Cheers,

Andrew

On Fri, Sep 8, 2017 at 11:07 AM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tuesday, August 8, 2017 at 2:26:02 PM UTC-7, Aaron Wu wrote:
> > This request from SSL.com is to include the “SSL.com Root Certification
> Authority RSA”, “SSL.com Root Certification Authority ECC”, “SSL.com EV
> Root Certification Authority RSA”, and “SSL.com EV Root Certification
> Authority ECC” root certificates, turn on the Email and Websites trust bits
> for the two non-EV roots, turn on the Websites trust bit for the two EV
> roots, and enable EV treatment for the two EV roots.
> >
> > SSL.com is a commercial organization that provides digital certificates
> in over 150 countries worldwide, with the goal of expanding adoption of
> encryption technologies and best practices through education, tools and
> expertise.
> >
> > The request is documented in the following bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1277336
> >
> > BR Self Assessment is here:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8881939
> >
> > Summary of Information Gathered and Verified:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8895068
> >
>
>
> I will greatly appreciate it if someone will review and comment on this
> root inclusion request from SSL.com.
>
> 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

Re: TrustCor root inclusion request

[Andrew R. Whalley via dev-security-policy]

Thanks Neil,

I've looked over the updated CP and CPS documents and have no further
comments or questions.

Cheers,

Andrew

On Tue, Aug 15, 2017 at 12:18 PM, Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Andrew,
>
> SHA-1 has been removed from the TrustCor OCSP list of acceptable hash
> algorithms for responder signatures.
>
> The minimum hash deemed acceptable now is SHA-256. We have updated the
> CP/CPS in section 6.1.5 to clarify that SHA-1 will no longer be honoured as
> a signature algorithm.
>
> Best regards,
>
> Neil Dunbar
> TrustCor CA Administrator
>
>
> > On 14 Aug 2017, at 20:48, Andrew Ayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > On Mon, 14 Aug 2017 20:27:05 +0100
> > Neil Dunbar via dev-security-policy
> >  wrote:
> >
> >> Note that TrustCor is capable of removing SHA-1 as a signature hash on
> >> OCSP responses, if the community determines it presents risk to the
> >> relying parties. However, this does raise the risk to some clients
> >> that would fail to understand the signature on the response.  We
> >> should prefer to service as many clients as faithfully as we can while
> >> remaining true to the security principles of this community.
> >
> > Yes, OCSP responses signed with SHA-1 do present a risk, since a
> > chosen prefix attack can be performed to forge OCSP responses and even
> > certificates:
> > https://www.mail-archive.com/dev-security-policy@lists.
> mozilla.org/msg02999.html
> >
> > Even if you technically constrain your OCSP responder certificates as
> > required by Mozilla policy section 5.1.1, forged OCSP responses are
> > still possible if you use SHA-1.  That would allow attackers to use
> > revoked certificates.  So it would be better if you didn't use SHA-1 at
> > all for OCSP responses.
> >
> > Thanks for your consideration of security feedback from the community.
> >
> > Regards,
> > Andrew
> > ___
> > 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
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TrustCor root inclusion request

[Andrew R. Whalley via dev-security-policy]

Greetings,

I have reviewed TrustCor's CP and CPS (both at version 1.3.1) and made the
following notes:

*CP* (http://www.trustcor.ca/resources/cp.pdf)

1.6.3
1.6.4
Nit:
Section 1.1 says that "Sections which do not apply to TrustCor CA, or where
TrustCor CA makes no authoritative statement, will have either the text “No
stipulation” or “Not Applicable”." but these sections are just blank.

3.3.1
"Level 2 Client certificates - demonstration of a pre-shared key and OTP
validation as described in Section 3.2.3 is sufficient to allow re- key."
however section 3.2.3 makes no mention of pre-shared key and OTP validation.

4.4.2 Publication of the certificate by the CA
Note that is at odds with any future CT requirement.

6.1.5
"OCSP responses may respond using the SHA-1 hash if the request used
SHA-1," Signing of OCSP responses with SHA1 is prohibited by the BRs
(section 7.1.3) after 1st Jan 2017 - though section 7.1.3 does state that
TrustCor does not, and never has, used SHA-1 as a component of any
signature algorithm on a certificate.

6.1.6
This section references version 1.3.0 of the BRs, which date from 2015.

*CPS* (http://www.trustcor.ca/resources/cps.pdf)

1.4.1
The maximum validity of the different certificate types, while within
what's allowed by the BRs, aren't consistent with the limits specified in
section 6.3.2 of the CP (e.g. 12 months vs 398 days).

2.2
https://catest1-revoked.trustcor.ca/ is not resolving.
https://catest1-expired.trustcor.ca/ is not resolving.
https://catest2-revoked.trustcor.ca/ is not resolving.
https://catest2-expired.trustcor.ca/ is not resolving.

2.2.1
Commitment to make incident reports public - very good.
(Note that at the moment
https://www.trustcor.ca/resources/issuance-incidents/ currently just
redirects to the home page)

3.2.2.4.7
Presuming "TrustCor will the authoritative DNS servers" should be "TrustCor
will *query* the authoritative DNS servers"

3.2.2.8
Fail shut CAA - good

3.2.6
While it's good that TrustCor will publish cross-signed certificates it
issues to other CAs, my understanding of section 3.2.6 of the BRs is that
it requires cross certifications that a CA obtains from other CAs (i.e.
where it is the Subject of the cert) to be published.

4.9.1.1
Even though section 4.9.2 states that a subscriber can request revocation
of their certificate, 4.9.1.1 does not list a subscriber request as a
reason for revocation.

4.9.1.2
I would like to hope that there are technical, not just business, controls
in place to limit the actions an "insufficiently aware staff member" could
perform.

7.1.2.2
Section 7.1.2.2 of the BRs states "certificatePolicies - This extension
MUST be present and SHOULD NOT be marked critical." for Subordinate CA
Certificates, however this section implies that certificatePolicies is only
specified for Enterprise Subordinate CAs.

7.1.2.3
For the Secure Mail profiles, the subjectAlternativeName is defined as
containing an "emailAddress". Should this not be rfc822Name?

7.1.2.4
It seems odd that this section references itself and 7.1.2.5.  Where these
meant to be 7.1.2.2 and 7.1.2.3?

The CP requires the subject key identifier and authority key identifier
extensions, but these are not specified in the cert profiles in the CPS.

7.1.6.3
This seems at odds with 7.1.2.2 of the BRs.

Those comments aside, I found both documents clear, well written, and they
provided sufficient detail to assess the policies in place.

Many thanks,

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

Re: Symantec: Update

[Andrew R. Whalley via dev-security-policy]

On Wed, May 10, 2017 at 2:06 PM, mono.riot--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wednesday, May 10, 2017 at 7:59:37 PM UTC+2, Itzhak Daniel wrote:
> > The next step, if Symantec wish to continue to use their current PKI in
> the future, should be logging (ASAP) *all* of the certificates they issued
> to a CT log, then we'll know how deep is the rabbit hole.
>
> already the case since '15
>
> https://security.googleblog.com/2015/10/sustaining-
> digital-certificate-security.html


The blog post is dated October 15, but the requirement* only came into
effect June 1st, 2016


> although I'm not certain if this applied only to certs issued under the
> Symantec brand.


Any certs issued by any Symantec CA, regardless of brand, unless the CA is
operated by a 3rd party under its own, separate, audit.

Andrew

*required for the cert to be trusted in Chrome.  They are still free to
issue certs that don't comply with the Chrome CT Policy, but those will
cause an interstitial warning in Chrome.

___
> 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: Include Renewed Kamu SM root certificate

[Andrew R. Whalley via dev-security-policy]

Hello,

I've read though the English language version of CP/CPS dated March 30,
2016 version 1 and made the following notes:

No version history at the front of the document.  This not required, but is
evidence of good document change management and is a useful reference to
see what's changed when coming back to reviewing docs.

1.2 Document Name and Identification

Document version number is 3, but the front page and headers say version
1.  Please clarify.

3.1.5 Uniqueness of Names

CN Field: Note that use of the common name is deprecated.

3.2.2 Authentication of Organization Identity

This section states "WHOIS records pertinent to domain name specified in
the certificate application shall be verified via 'www.nic.tr'". It would
be useful to have more detail on the validation method. See section 3.2.2.4
of the Baseline Requirements.

4.9.3 Procedure for Revocation Request

The Baseline Requirements for this section state: "The CA SHALL provide
Subscribers, Relying Parties, Application Software Suppliers, and other
third parties with clear instructions for reporting suspected Private Key
Compromise, Certificate misuse, or other types of fraud, compromise,
misuse, inappropriate conduct, or any other matter related to Certificates.
The CA SHALL publicly disclose the instructions through a readily
accessible online means."

As such instructions aren't included in the CP/CPS, could you point to
where they can be found?

6.5.1 Specific Computer Security Technical Requirements

Please make sure use of anti virus is properly risk managed. There have
been a worrying number of high severity bugs in popular anti virus
software, including privileged remote code execution.

7.2.2 CRL and CRL Entry Extensions

Though optional, CRL reason codes are encouraged.

9.4.3 Information Not Deemed Private

The contents of publicly trusted certificates should always be treated as
public even if such a an agreement or contract is in place.

10.3 End Entity SSL Certificate Template

For Serial Number, a unique number is insufficient, per BRs "CAs SHALL
generate non‐sequential Certificate serial numbers greater than zero (0)
containing at least 64 bits of output from a CSPRNG."

--

Overall the document was clear and well written and didn't contain anything
too worrying.

Cheers,

Andrew

On Thu, Feb 2, 2017 at 11:45 PM, Kathleen Wilson 
wrote:

> This request from the Government of Turkey, Kamu Sertifikasyon Merkezi
> (Kamu SM), is to include the “TUBITAK Kamu SM SSL Kok Sertifikasi - Surum
> 1” root certificate, and enable the Websites trust bit. This SHA-256 root
> certificate will eventually replace the SHA1 “TÜBİTAK UEKAE Kök Sertifika
> Hizmet Sağlayıcısı - Sürüm 3” root certificate that was included via
> Bugzilla Bug #381974. The old root certificate expires in August, 2017.
>
> Note that the CA has indicated that since Kamu SM is a government CA , the
> CA only issues certificates to government-owned domains (restricted by
> these TLDs: gov.tr, k12.tr, pol.tr, mil.tr, tsk.tr, kep.tr, bel.tr, edu.tr
> and org.tr ) and does not issue any certificates outside of Turkey. So,
> Mozilla may constrain this root to those domains.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1262809
>
> And in the pending certificates list:
> https://wiki.mozilla.org/CA:PendingCAs
>
> Summary of Information Gathered and Verified:
> https://bug1262809.bmoattachments.org/attachment.cgi?id=8832967
>
> * Root Certificate Download URL:
> https://bugzilla.mozilla.org/attachment.cgi?id=8738995
> http://depo.kamusm.gov.tr/ssl/SSLKOKSM.S1.cer
>
> * The primary document, the SSL CP/CPS, is provided in both Turkish and
> English.
>
> Document Repository: http://depo.kamusm.gov.tr/ilke/
> SSL CP/CPS:
> http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_Tr.pdf
> http://depo.kamusm.gov.tr/ilke/KamuSM_CPS/KamuSM_CPS_En.pdf
>
> * CA Hierarchy: This root certificate has internally operated subordinate
> CAs that issue SSL end-entity certificates.
>
> * This request is to turn on the Websites trust bit.
> ** SSL CP/CPS section 3.2.2: Authentication of government agencies having
> requested OV SSL certificate from Kamu SM shall be performed by way of
> verification from official correspondences made between Kamu SM, relevant
> government agency and relevant channels of domain ownership (e.g., nic.tr
> ).
> All applications made to Kamu SM shall be supported with legal documents
> that shall authenticate the following information and some of this
> information shall be included within the Subject field:
> …...
> Residence address of applicant government agency is taken as a basis in OV
> SSL applications. Legal status, identification information, domain name,
> organization representative, presence of application, CSR information and
> other similar information of applicant should be verified. Since the
> organization authentication is of high importance while issuing OV SSL
> 

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

[Andrew R. Whalley]

Hello,

Thank you for the links.  I note, however, that there's at least one
difference between the native language version and the English translation:

http://www.gdca.com.cn/cps/cps version 4.3 has a section 4.2.4 covering
CAA.
https://bug1128392.bmoattachments.org/attachment.cgi?id=8795091 version 4.3
in English has no such section.

The fact there's a discrepancy is rather worrying.  Could you please check
and let me know if there are any other substantive differences between the
Chinese and English versions?

Cheers,

Andrew

On Mon, Sep 26, 2016 at 7:17 PM, <wangsn1...@gmail.com> wrote:

> 在 2016年9月27日星期二 UTC+8上午4:15:00，Andrew R. Whalley写道：
> > Hello,
> >
> > I have completed a read through of the English translations of the CP
> > (v1.2) and CPS (v4.1). Before I post my comments I wanted to see if there
> > were any more recent translations?  It looks like the local language
> > versions are 1.4 and 4.3 respectively.
> >
> > Many thanks,
> >
> > Andrew
> >
> > On Wed, Aug 3, 2016 at 2:45 PM, Kathleen Wilson <kwil...@mozilla.com>
> wrote:
> >
> > > This request from Guangdong Certificate Authority (GDCA) is to include
> the
> > > "GDCA TrustAUTH R5 ROOT" certificate, turn on the Websites trust bit,
> and
> > > enabled EV treatment.
> > >
> > > GDCA is a nationally recognized CA that operates under China’s
> Electronic
> > > Signature Law. GDCA’s customers are business corporations registered in
> > > mainland China, government agencies of China, individuals or mainland
> China
> > > citizens, servers of business corporations which have been registered
> in
> > > mainland China, and software developers.
> > >
> > > The request is documented in the following bug:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1128392
> > >
> > > And in the pending certificates list:
> > > https://wiki.mozilla.org/CA:PendingCAs
> > >
> > > Summary of Information Gathered and Verified:
> > > https://bugzilla.mozilla.org/attachment.cgi?id=8749437
> > >
> > > Noteworthy points:
> > >
> > > * Root Certificate Download URL:
> > > https://bugzilla.mozilla.org/attachment.cgi?id=8748933
> > > https://www.gdca.com.cn/cert/GDCA_TrustAUTH_R5_ROOT.der
> > >
> > > * The primary documents are provided in Chinese.
> > >
> > > CA Document Repository: https://www.gdca.com.cn/
> > > customer_service/knowledge_universe/cp_cps/
> > > http://www.gdca.com.cn/cp/cp
> > > http://www.gdca.com.cn/cps/cps
> > > http://www.gdca.com.cn/cp/ev-cp
> > > http://www.gdca.com.cn/cps/ev-cps
> > >
> > > Translations into English:
> > > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8650346
> > > CPS: https://bugzilla.mozilla.org/attachment.cgi?id=8688749
> > >
> > > * CA Hierarchy: This root certificate has internally-operated
> subordinate
> > > CAs
> > > - GDCA TrustAUTH R4 SSL CA (issues 2048-bit SSL certs)
> > > - GDCA TrustAUTH R4 Generic CA (issues 2048-bit individual certs)
> > > - GDCA TrustAUTH R4 CodeSigning CA (issues 2048-bit CodeSigning certs)
> > > - GDCA TrustAUTH R4 Extended Validation SSL CA (issues 2048-bit EV SSL
> > > certs)
> > > - GDCA TrustAUTH R4 Extended Validation Code Signing CA (issues
> 2048-bit
> > > EV CodeSigning certs)
> > >
> > > * This request is to turn on the Websites trust bit.
> > >
> > > CPS section 3.2.5: For domain verification, GDCA needs to check the
> > > written materials which can be used to prove the ownership of
> corresponding
> > > domain provided by applicant. Meanwhile, GDCA should ensure the
> ownership
> > > of domain from corresponding registrant or other authoritative
> third-party
> > > databases. During the verification, GDCA needs to perform the following
> > > procedures:
> > > 1. GDCA should confirm that the domain's owner is certificate applicant
> > > based on the information queried from corresponding domain registrant
> or
> > > authoritative third-party database and provided by applicant.
> > > 2. GDCA should confirm that the significant information (such as
> document
> > > information of applicant) in application materials are consistent with
> the
> > > reply of domain's owner by sending email or making phone call based on
> the
> > > contact information (such as email, registrar, administrator's email
> > > published at this domain's website, etc.) queried fro

Re: Is Firefox SHA-1 Deprecation Policy configurable?

[Andrew R. Whalley]

For Chrome, there's the EnableSha1ForLocalAnchors policy that was
introduced in Chrome 54.  That will operate as described here

.

Andrew

On Sat, Sep 17, 2016 at 10:49 AM,  wrote:

> I think that's the security.pki.sha1_enforcement_level pref [1][2].
>
> Regards,
> Jonas
>
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=942515#c35
> [2]
> https://blog.mozilla.org/security/2016/01/06/man-in-
> the-middle-interfering-with-increased-security/
>
>
>
> Am 16.09.2016 um 16:53 schrieb therickf...@gmail.com:
> > Working with a client on "workarounds" for avoiding SHA-1 deprecation on
> a system they are woefully behind on updating for SHA-256 compatible.  They
> asked/stated that Chrome & probably Firefox were "configurable" in regards
> to shutting out the trust for SHA-1 SSL/TLS certs. I'm skeptical as I
> haven't seen anything like that.
> >
> > Is there any configurability in Firefox regarding this (e.g. from a GPO
> perspective - Windows environment), or is all the SHA-1 deprecation policy
> embedded in the Firefox code - to be enforced when that update is pushed
> out (presumably on/around 1/1/17)? Thanks
> >
> > Rick
> > ___
> > 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
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Amazon Root Inclusion Request

[Andrew R. Whalley]

Here are the notes from my read-through. I commend Amazon for the clarity
of their CP and CPS.

Reviewed Amazon Trust Services Certificate Policy

Version 1.0.3

"This [CP] is intended to communicate the minimum operating requirements
for CAs in the Amazon PKI. By design, it closely follows the CA/Brower
[sic] Forum Guidelines and Requirements and only deviates when an
Application Software Supplier has requirements that are stricter…"


Good.

"Creative Commons Attribution-NoDerivatives 4.0 International License"

Good.

1.1.2 Types of Certificate

"A certificate is a Root CA-certificate if it a Policy CA-certificate and
the subject is designated by the CA as a Root CA in the CA’s CPS."

The Root CA-Certificates designated by the CPS are self signed, and match
the definition of "self issued" from section 1.1.2.1.  However 1.1.2.1.7
says Root CA-Certificates are Policy CA-certificates and 1.1.2.1.4 says
Policy CA Certificates are cross-certificates, and 1.1.2.1 says that
cross-certificates are not self-issued certificates.

1.1.2.2 End-Entity Certificates

"CAs must not issue EndEntity Certificates that simultaneously meet the
criteria of multiple of the following categories."

Good.

3.2.1 Method to prove possession of private key

Section is blank.  Assuming "No stipulation" rather than missing text?

6.5.1.4 Authentication: Passwords and Accounts

"For accounts that are accessible from outside a Secure Zone or High
Security Zone, require that passwords have at least eight (8) characters…"

Eight characters seems a bit short.

6.6.3 Life cycle security controls

"apply recommended security patches to Certificate Systems within six
months of the security patch’s availability"

Six months seems a bit long.

7.1.4.4 Subject Information for Extended Validation Server Authentication
certificates

Formatting bug - not rendered as a table.

(suggests that this came from a plaintext original - is that available
anywhere?)

Amazon Trust Service Certificate Practice Statement v1.0.4

3.2.2 Authentication of organization identity

"Amazon does not use methods 9, 10, or 11 for validating wildcard names"

There is no method 11

4.2.1 Performing identification and authentication functions

"Amazon Root CAs do not check CAA records prior to issuing certificates."

Pity.

4.4.3 Notification of certificate issuance by the CA to other entities

Amazon may notify the public of the issuance of a certificate by adding it
to one or more publicly accessible  … CT Logs

Good

Appendix B: Certificate Profiles

"If the signatureAlgorithm uses SHA-1, the serial number must contain at
least 64 bits of randomly generated entropy"

What about non SHA-1?

Andrew

On Thu, Aug 4, 2016 at 5:36 PM, Kathleen Wilson  wrote:

> This request from Amazon is to enable EV treatment for the
> currently-included “Starfield Services Root Certificate Authority - G2
> certificate, and to include the following 4 new root certificates, turn on
> the Email and Websites trust bits for them, and enable EV treatment for all
> of them.
> - Amazon Root CA 1 (RSA key with a 2048 bit long modulus)
> - Amazon Root CA 2 (RSA key with a 4096 bit long modulus)
> - Amazon Root CA 3 (EC key on the NIST P-256 curve)
> - Amazon Root CA 4 (EC key on the NIST P-384 curve)
> All 4 of these new Amazon root certificates have cross-signed with the
> currently-included “Starfield Services Root Certificate Authority - G2”
> certificate.
>
> The Amazon PKI is run by Amazon Trust Services ("Amazon"). Customers of
> the Amazon PKI are the general public. Amazon does not require that
> customers have a domain registration with Amazon, use domain suffixes where
> Amazon is the registrant, or have other services from Amazon.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1172401
>
> And in the pending certificates list:
> https://wiki.mozilla.org/CA:PendingCAs
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=8734171
>
> Noteworthy points:
>
> * The primary documents are provided in English.
>
> CA Document Repository  https://www.amazontrust.com/
> CP: http://www.amazontrust.com/repository/cp.pdf
> CPS: http://www.amazontrust.com/repository/cps.pdf
> Subscriber Agreement: https://www.amazontrust.com/repository/sa-1.1.pdf
>
> * CA Hierarchy: The Amazon Root CAs will have internally-operated
> subordinate CAs that will issue certs for SSL, Code Signing, Email, etc.
> There will be separate subCAs for EV certificate issuance.
> Externally-operated subCAs are permitted according to the CPS.
>
> * This request is to enable the Email and Websites trust bits for all 4 of
> the new Amazon root certs. The request is to also enable EV treatement for
> all 4 of the new Amazon root certs, as well as for the “Starfield Services
> Root Certificate Authority - G2” cert that is already included in NSS.
>
> CPS section 3.2.2:
> Amazon uses the following methods to confirm that 

Re: Japan GPKI Root Renewal Request

[Andrew R. Whalley]

On Fri, Aug 5, 2016 at 5:39 AM, Peter Kurrasch  wrote:

> Kathleen--
>
> As I understand it, the request is for only CA2(Root) to be included in
> the trust store. Is that correct?
>
> The CP/CPS document submitted for the CA2(Root) hardly seems sufficient to
> satisfy anyone for one simple reason: there is no detail! I'm surprised the
> auditors (KPMG in this case) found this to be acceptable. If the CA2(Sub)
> ‎is not to be included in the Mozilla trust store then I don't see how it's
> CP/CPS can be reviewed for consideration here.
>

I've been mulling over this too.  While it does say it complies with the
BRs and they take priority, it is indeed very under specified.

I would refer the Government of Japan, Ministry of Internal Affairs and
Communications to the Amazon Trust Services CP/CPS as an example of how to
adhere closely to the BRs while still providing sufficient detail.

Andrew


> My recommendation is to reject this request and ask that the root's
> documentation be rewritten to reflect the policies and procedures that
> apply to all certs that chain to this root.
>
>
> *From: *Eric Mill
> *Sent: *Wednesday, July 20, 2016 8:15 PM‎
>
> For some reason, Gmail split up this thread into two for me. In case anyone
> else is having similar issues, here's the original detail for this request:
>
> On Wed, Apr 27, 2016 at 4:56 PM, Kathleen Wilson 
> wrote:
>
> > This request by the Government of Japan, Ministry of Internal Affairs and
> > Communications, is to include the GPKI 'ApplicationCA2 Root' certificate
> > and enable the Websites trust bit. This new root certificate has been
> > created in order to comply with the Baseline Requirements, and will
> > eventually replace the 'ApplicationCA - Japanese Government' root
> > certificate that was included via Bugzilla Bug #474706. Note that their
> > currently-included root certificate expires in 2017, and will be removed
> > via Bugzilla Bug #1268219.
> >
> > The request is documented in the following bug:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=870185
> >
> > And in the pending certificates list:
> > https://wiki.mozilla.org/CA:PendingCAs
> >
> > Summary of Information Gathered and Verified:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8673399
> >
> > Noteworthy points:
> >
> > * The primary documents are the Root and SubCA CP/CPS, provided in
> > Japanese and English.
> >
> > Document Repository (Japanese):
> > http://www.gpki.go.jp/apca/cpcps/index.html
> > Document Repository (English):
> > https://www2.gpki.go.jp/apca2/apca2_eng.html
> > Root CP/CPS:
> > https://www2.gpki.go.jp/apca2/cpcps/cpcps_root_eng.pdf
> > SubCA CP/CPS:
> > https://www2.gpki.go.jp/apca2/cpcps/cpcps_sub_eng.pdf
> >
> > * CA Hierarchy: This root certificate has one internally-operated
> > subordinate CA that issues end-entity certificates for SSL and code
> signing.
> >
> > * This request is to turn on the Websites trust bit.
> >
> > SubCA CP/CPS section 3.2.2, Authentication of organization identity
> > As for the application procedure of a server certificate, ... the LRA
> > shall verify the authenticity of the organization to which the subscriber
> > belongs according to comparing with organizations which were written in
> the
> > application by directory of government officials that the Independent
> > Administrative Agency National Printing Bureau issued.
> >
> > SubCA CP/CPS section 3.2.3, Authentication of individual identity
> > As for the application procedure of a server certificate, ... the LRA
> > shall verify the authenticity of the subscriber according to comparing
> with
> > name, contact, etc. which were written in the application by directory of
> > government officials that the Independent Administrative Agency National
> > Printing Bureau issued.
> > The LRA also check the intention of an application by a telephone or
> > meeting.
> >
> > SubCA CP/CPS section 4.1.2, Enrollment process and responsibilities
> > (1) Server certificate
> > The subscriber shall apply accurate information on their certificate
> > applications to the LRA.
> > The LRA shall confirm that the owner of the domain name written as a
> > name(cn) of a server certificate in the application form belongs to
> > Ministries and Agencies who have jurisdiction over LRA, or its related
> > organization with the thirdparty databases and apply accurate information
> > to the Application CA2(Sub).
> >
> > * Mozilla Applied Constraints: This CA has indicated that the CA
> hierarchy
> > may be constrained to the *.go.jp domain.
> >
> > * Root Certificate Download URL:
> > https://bugzilla.mozilla.org/attachment.cgi?id=8673392
> > https://www.gpki.go.jp/apca2/APCA2Root.der
> >
> > * EV Policy OID: Not requesting EV treatment
> >
> > * Test Website:
> > https://www2.gpki.go.jp/apca2/apca2_eng.html
> >
> > * CRL URLs:
> > http://dir.gpki.go.jp/ApplicationCA.crl
> > http://dir2.gpki.go.jp/ApplicationCA2Root.crl
> > 

TSYS Application for SHA-1 Issuance - Counter-cryptanalysis

[Andrew R. Whalley]

Greetings,

I have run the tool provided by dr.ir. Marc Stevens [1] on the
tbsCertificates provided by Symantec [2]

And see no evidence of collisions:

$ ./sha1dcsum_partialcoll *.tbs
6ead26663275c388662dfdbc23ff0a76cdcf74dc  ssl1.tsysacquiring.net.1.tbs
3365793f36c197047b2f595c0f85c67b807c765f  ssl1.tsysacquiring.net.2.tbs
3c47155a5d9880a6893925e1c4479f914b3b9ffe  ssl1.vitalps.net.1.tbs
d130d1a8c51bce7323ba984b2f6298d0750405f4  ssl1.vitalps.net.2.tbs
c9eb52c30bfaaaba5a1e060723e3c9e4b25f7b1e  ssl2.vitalps.net.1.tbs
3698794f1cabc3036380cc2adbc2805393098c45  ssl2.vitalps.net.2.tbs
e7233e69a89b6b7568f790482b73f635d2464a95  ssl3.vitalps.net.1.tbs
9c7bbae0fc9b08c5304908bd956c5b4b37c4e1c7  ssl3.vitalps.net.2.tbs

I'd be interested to know if anybody else replicates this.

Marc - I believe that the tool as posted doesn't give assurance to the full
80 bit security level.  If that's true do you have an estimate of the
security level it does provide?

Many thanks,

Andrew

[1] see https://marc-stevens.nl/research/ &
https://svn.marc-stevens.nl/collisiondetection/
[2] https://cabforum.org/pipermail/public/2016-July/007999.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DocuSign (OpenTrust/Keynectis/Certplus) root renewal request

[Andrew R. Whalley]

Thank you Erwann.  I have no other questions at this time.

On Thu, Apr 28, 2016 at 7:13 AM, Erwann Abalea  wrote:

> Bonjour,
>
> Le vendredi 8 avril 2016 01:38:09 UTC+2, awha...@google.com a écrit :
> > OpenTrust has requested EV treatment in Chrome, with bug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=385090
> >
> > As such I've reviewed the "EV SSL CA Certificate Practice Statement"
> version 0.8 dated Feb 1st 2016, and have the following comments and
> questions for them:
> >
> > 1.1 Overview
> >
> > We encourage honouring CAA records, even though it's not currently
> required.  We also encourage CAs to publish how they would use CAA values
> in the future if they were to support it, to allow domain owners to start
> creating such records.
>
> Ok, we'll adapt our procedures if necessary.
>
>
> > For Club EV and ISP EV, it says they perform "All checks required to
> issue EV Certificates, in accordance with this CPS."  Could you confirm
> that KEYNECTIS EV still performs the final cross check, per 3.2.6
> Validation of Authority.
>
> As described in sections 4.2.1.2 and 4.2.1.3, Club EV and ISP EV offers
> can't be open unless KEYNECTIS EV CA has performed necessary identification
> and authentication processes under dual control (RA operator 1 and RA
> operator 2), to perform this cross-check.
>
>
> > 1.2 Document Name and Identification
> >
> > The application lists 1.3.6.1.4.1.22234.2.5.2.3.1 as the EV OID, but
> this section mentions that you're moving to 1.3.6.1.4.1.22234.2.14.3.11.
> Are both being requested?  If so, please update in the Chromium bug.
>
> The Google Chromium application request will be updated accordingly.
>
>
> > 1.5.4 CPS Approval Procedure
> >
> > Please clarify the exact details regarding "Parts of the CPS are remains
> (sic) confidential and are not published."
>
> Internal procedures, such as management of badges, management of access
> controls (physical and logical), management of secret shares, etc.
>
>
> > 1.6 Definitions and Acronyms
> >
> > Independent confirmation from applicant: definition missing.
>
> We meant to copy/paste the definition from EV guidelines, and missed it.
> This will be corrected in the next CPS revision.
>
>
> > 3.2.2.4 Verification of an Entity Domain Name
> >
> > "For Government Entity Applicants, the CA relies on the domain name
> listed for that entity in the records of the QGIS in Applicant's
> Jurisdiction to verify Domain Name."
> >
> > Please describe how this is covered by one of items 1 to 7 of section
> 3.2.2.4 of the Baseline Requirements.
>
> This is an unfortunate mix, inspired by section 3.2.2.1 (dealing with
> Entity legal existence verifications). This phrase will be removed in the
> next CPS revision. We only use methods 1 to 4.
>
>
> > 4.1.2.1 K.EV offer
> >
> > "at the following address:" - no address is specified
>
> That's an error, the proper address is transmitted with the purchase
> order. This will be corrected in the next CPS revision.
>
>
> > 4.2.1.1 K.EV offer
> >
> > Missing section reference in the 7th bullet
>
> The next 2 bullets should have been right-indented, as in sections 4.2.1.2
> and 4.2.1.3. Will be corrected in the next CPS revision.
>
>
> > 4.9.4 Time within Which CA Must Process the Revocation Request
> >
> > "OPENTRUST RA for revocation is available from 9:00 am to 06:00 pm
> Monday to Friday, except during bank holidays."
> >
> > Baseline Requirements section 4.9.1.1. "The CA SHALL revoke a
> Certificate within 24 hours", and 4.9.3. "The CA SHALL maintain a
> continuous 24x7 ability to accept and respond to revocation requests and
> related inquiries.".  Please confirm that a revocation request can go
> directly to the CA if the RA isn't currently open.
>
> This 9-18 Mon-Fri time frame is only for OPENTRUST RA human personnel.
> KEYNECTIS EV CA online revocation service is available on a 24x7 basis, as
> written on the preceding page.
>
>
> > 5.8 EV CA component termination
> >
> > Several sections of the Baseline Requirements refer to CA being revoked
> making arrangements for another CA to provide revocation support for issued
> certificates.  Would such an arrangement be considered here?
>
> No.
>
>
> > 7.1 Certificate Profile
> >
> > Key length still mentions 1024 bits, without caveat.
> >
> > Public key algorithm still mentions SHA1, without caveat.
>
> 1024 bits and SHA1 were not removed from the CPS, this will be done in the
> next CPS revision.
> In the meantime, we of course follow CABF BR regarding key sizes and
> signature algorithm (keys smaller than 2048 bits are rejected, and
> certificates are signed with SHA2 only since 01/01/2016).
> ___
> 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

Re: ComSign Root Renewal Request

[Andrew R. Whalley]

It looks like https://fedir.comsign.co.il/test.html is trusted by OS X,
which for me meets the criteria for a Publicly‐Trusted Certificate.  That
certificate was issued on 2nd Feb, so I presume the 90 day clock is ticking.





Andrew R. Whalley |  Crypto Wrangler |  Chrome Networking and Security  |  +1
415-736-7248

On Wed, Mar 30, 2016 at 12:20 AM, Eli Spitzer <elis.co...@gmail.com> wrote:

> On Wednesday, March 30, 2016 at 4:36:44 AM UTC+3, Andrew Whalley wrote:
> > Hello Jesus,
> >
> > Great points!
> >
> > > Reviewing the BR audit report of Comsign Ltd I have a few doubts
> regarding the audits accepted by Mozilla and may someone can help me.
> > >
> > > The BR audit was conducted according to the WebTrust forCertification
> Authorites - SSL Baseline Requirements Audit Criteria version 1.1 and it's
> a point-of-time (as of April 26, 2015).
> > > Although this audit criteria is accepted according to the Mozilla CA
> Certificate Inclusion Policy 2.2, the BR audit version 1.1 was superseded
> by Webtrust SSL Baseline with Network Security version 2.0 (effective for
> audit periods starting on or after July 1, 2014).
> > >
> > > Webtrust audit criteria states that "The point-in-time readiness
> assessment shall be completed no earlier than twelve (12) months prior to
> issuing Publicly-Trusted Certificates and shall be followed by a complete
> audit under such scheme within ninety (90) days of issuing the first
> Publicly-Trusted Certificate. (See SSL Baseline Requirements Section
> 17.4)". Should Mozilla expect a complete audit 90 days after the
> point-in-time BR audit report or after the first certificate (I don't know
> when was issued)?
> >
> > Neither of the other audit reports I can find by Sharony - Shefler & Co,
> for "ComSign CA" (https://bugzilla.mozilla.org/attachment.cgi?id=868616)
> and "Comsign Secured CA" (
> https://bugzilla.mozilla.org/attachment.cgi?id=8686170), give an audit
> duration and only state a point in time.
> >
> > Eli, please confirm when we can expect a period audit and what period it
> will cover.
> >
> > > In addition and regarding the OCSP Responder certificate with Serial
> Number: 0e:2b:cd:a4:aa:4f:8f:80:da:16:94:4e:ba:33:35:33, the validity is 3
> years. According the RFC 6960 "A CA may specify that an OCSP client can
> trust a responder for the lifetime of the responder's certificate.  The CA
> does so by including the extension id-pkix-ocsp-nocheck.  This SHOULD be a
> non-critical extension. The value of the extension SHALL be NULL. CAs
> issuing such a certificate should realize that a compromise of the
> responder's key is as serious as the compromise of a CA key used to sign
> CRLs, at least for the validity period of this certificate.  CAs may choose
> to issue this type of certificate with a very short lifetime and renew it
> frequently." Which is the maximum acceptable lifetime for this type of
> certificates that contains the id-pkix-ocsp-nocheck extension?
> >
> > Three years seems excessive, but doesn't appear to be uncommon:
> >
> > http://ocsp.entrust.net
> > Not Before: Jun  4 19:15:34 2015 GMT
> > Not After : Jun  4 19:45:34 2017 GMT
> >
> > http://crl.quovadisglobal.com/qvocag2.crl
> > Not Before: May 28 14:33:37 2014 GMT
> > Not After : May 28 14:33:37 2017 GMT
> >
> > And there are some are valid for much longer:
> >
> > http://root-c3-ca2-2009.ocsp.d-trust.net
> > Not Before: Jul  2 10:03:07 2013 GMT
> > Not After : Nov  5 08:35:58 2029 GMT
> >
> > It sounds like limiting the validity period of OCSP signing certs would
> be an excellent topic to discuss generally, but I don't consider it a
> blocking issue for this application.
> >
> > Andrew
>
> Hello Andrew and Jesus,
> As mentioned, the Audit reports that we have are only Point-in-Time
> reports. We haven't started issuing public certificates yet, and at the
> moment we are not planning to do so until the inclusion in the Mozilla Root
> program.
> Once we finish the inclusion process and start issuing public certificates
> we will conduct a period audit as required by WebTrust BR
> Eli
> ___
> 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: SHA-1 S/MIME certificates

[Andrew R. Whalley]

On Wed, Mar 30, 2016 at 2:23 PM, Kathleen Wilson 
wrote:

> On 3/30/16 1:53 PM, Jeremy Rowley wrote:
>
>> I think a required move away from SHA1 client certs requires a bit more
>> planning.
>>
>> 1) There hasn't been a formal deprecation of all SHA-1 certificates in
>> any root store policy. There has been a formal deprecation by the CAB Forum
>> of SHA1 server certificates. Considering many of the client cert issuance
>> is governed by various national schemes (FBCA in the US and the Qualified
>> Cert program in the EU), care is necessary in enacting policies that impact
>> the use of client certificates. Although I recognize the need for Mozilla
>> to ensure a safe onine experience for all its users, I'm sure they don't
>> want to undermine entire trust frameworks built on these certificates.
>> (Yes, I know FBCA requires SHA2 now).
>>
>> 2) The browsers are already deploying code to reject SHA1 certificates
>> encountered. If this is true, what is the harm in continued SHA1 client
>> certificate issuance until the national schemes have all updated their
>> requirements? Mozilla is protected but the national bodies (and financial
>> institutions) can continue using their software for client authentication.
>> I do think we should move to SHA2, but I don't think the prior notice has
>> occurred with respect to SHA1 client certs.
>>
>> 3) Because Mozilla doesn't have a policy against reissuance of SHA1
>> intermediates for client certificates, I don't think your suggestion to
>> only permit reissuance of limited SHA1 intermediates is feasible. I do
>> think requiring a constraint against general SHA1 intermediates (that lack
>> technical restrictions to prevent server certs) is a good idea to ensure
>> the intermediates are only used for s/MIME or code signing.
>>
>> 4) Documenting why outdated algorithms/key sizes/anything else are used
>> always ends up being "For support of legacy devices". I don't see much
>> value in that. It becomes an exercise in creating an automatic label
>> applied to each certificate.
>>
>> In all, I think clientAuth certs are different than serverAuth certs. CAs
>> issuing clientAuth certs wouldn't necessarily be aware of the intent to
>> deprecate.  I also do not think Mozilla has as large of stake in client
>> certificates as it does server certs. Therefore, any plan to move away from
>> SHA1 client certs should start with:
>> A) An announcement that client certs will be deprecated
>> B) A question to the public about what software is still requiring the
>> use of SHA1 certs and the impact of requiring SHA2 certs, and
>> C) A date when SHA1 client certs will be deprecated
>>
>> Again, I'm not opposed to moving to SHA2 client certs, but I don't think
>> Mozilla has conveyed to the public its intent to do so.
>>
>>
>>
>
> I think Jeremy is correct, that Mozilla's previous communications about
> SHA-1 certs was only in regards to TLS/SSL certs.
>
> Would anyone object to me changing Actions 1a and 1b to the following?
>

Looks reasonable to me.


> (note, using date 2016-04-01 for the CAs who don't have the Websites trust
> bit enabled will make it so we can easily filter out those responses)
> ~~
> ACTION #1a: As previously communicated, CAs should no longer be issuing
> SHA-1 certificates chaining up to root certificates included in Mozilla's
> CA Certificate Program. This includes TLS/SSL certificates, as well as any
> intermediate certificates that they chain up to. Check your systems and
> those of your subordinate CAs to ensure that SHA-1 based TLS/SSL
> certificates chaining up to your included root certificates are no longer
> being issued, and that any such certificates issued after 2016-01-01 have
> been revoked. Please enter the last date that a SHA-1 based TLS/SSL
> certificate was issued that chained up to your root certificates included
> in Mozilla's program. If your included root certificates do not have the
> Websites trust bit enabled, then please enter 2016-04-01. (Required)
>
>
> ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL
> certificates that chain up to your root certificates included in Mozilla's
> CA Certificate Program will either expire or be revoked. If your included
> root certificates do not have the Websites trust bit enabled, then enter
> 2016-04-01.
>
> As previously communicated we plan to show the “Untrusted Connection”
> error whenever a SHA-1 certificate is encountered in Firefox after January
> 1, 2017.
>
> We recommend that you put safeguards into place that will prevent the
> future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1
> based intermediate certificates that chain up to your root certificates
> included in Mozilla's CA Certificate Program. (Required)
>
> ~~
>
>
> I think we can keep Action 1c as-is, because option (d) should capture
> information about issuance of S/MIME certs.
>
>
> Thanks,
> Kathleen
>
>
>
> ___
> 

Re: FNMT Root Inclusion Request

[Andrew R. Whalley]

Hello Rafa,

Thank you for your reply.  The background to my question was really about
ensuring ongoing compliance.  I believe that an initial audit to verify
that no TLS certificate has ever been issued by "AC FNMT Usuarios", and a
recurring annual audit to confirm that remains so, is acceptable.  However,
given the "AC FNMT Usuarios" is technically capable, if the audit ever
comes back inconclusive or if there is ever any doubt that such an audit
could detect any inadvertent issuance, the assumption should be that
miss-issuance has occurred and it would be reasonable to act accordingly.

With that stipulation, I don't have any objections to the roots in question
continuing the Mozilla inclusion process.

Andrew

On Mon, Mar 14, 2016 at 11:00 AM,  wrote:

> > However I still hold out some hope that the current proposal could be
> workable.  I'm sorry if I missed it in the thread or bug, what is the
> rationale that a "AC FNMT Usuarios" doesn't require an ongoing WebTrust SSL
> BRs audit?
> >
> Hi Andrew.
>
> As specified at CABForum Baseline Requirements documents, these
> requirements only address certificates intended to be used for
> autenticating servers accessible through Internet.
>
> Notice that "AC FNMT Usuarios" issues qualified certificates for natural
> persons (citizens). Therefore, it can't be audited conforming BR
> requirements because we don't issue SSL certs with this subCA (in fact, we
> have technical configuration restrictions to prevent SSL certs issuing).
>
> As I mentioned, "AC FNMT Usuarios" only issues "qualified certificates"
> where ETSI 101 456 audit criteria applies. Nevertheless, because this
> subordinate CA don't have the EKU extension, according to
> "CA:BaselineRequirements" document at mozilla wiki, "AC FNMT Usuarios" is
> "in scope" and it's necessary to perform "procedures to confirm that there
> are no SSL certificates".
>
> Best Regards,
>
> Rafa
> ___
> 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