Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Charles Reiss via dev-security-policy]

On 07/17/2017 11:21 AM, Ben Wilson wrote:

Dear Jonathan,

Thank you for bringing this to our attention.  We have contacted Intesa 
Sanpaolo regarding this error and have asked them to correct it as soon as 
possible.
Sincerely yours,


This CA also issued a recent certificate for the unqualified dNSName 
'webinterfacestrong': https://crt.sh/?id=177606495

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

Re: Certificate with invalid dnsName

[Charles Reiss via dev-security-policy]

On 07/19/2017 06:03 PM, Tom wrote:

Following that discovery, I've search for odd (invalid?) DNS names.
Here is the list of certificated I've found, it may overlap some 
discovery already reported.
If I'm correct, theses certificate are not revoked, not expired, and 
probably trusted by Mozilla (crt.sh issuer are marked trusted by 
Mozilla, but not all).


Annotating these certs:


Starting with *:


I believe this cert is presently untrusted by Mozilla due to revocation 
of all paths to the Federal PKI:

https://crt.sh/?id=7211484*eis.aetc.af.mil


chains to StartCom (and all of these from StartCom are minor compared to 
StartCom's other problems):

https://crt.sh/?id=10714112*g10.net-lab.net


chains to Baltimore CyberTrust Root (DigiCert):

https://crt.sh/?id=48682944*nuvolaitaliana.it


chains to StartCom:

https://crt.sh/?id=15736178*assets.blog.cn.net.ru
https://crt.sh/?id=17295812*dev02.calendar42.com
https://crt.sh/?id=15881220*dev.1septem.ru
https://crt.sh/?id=15655700*assets.blog.cn.net.ru
https://crt.sh/?id=17792808*quickbuild.raptorengineering.io





Starting with -:


chains to QuoVadis:
https://crt.sh/?id=54285413
-d1-datacentre-12g-console-2.its.deakin.edu.au


chains to StartCom:

https://crt.sh/?id=78248795-1ccenter.777chao.com





Multiple *.:


chains to QuoVadis:

https://crt.sh/?id=13299376*.*.victoria.ac.nz


I believe this cert is presently trusted by Mozilla only via a 
technically constrained subCA:

https://crt.sh/?id=44997156*.*.rnd.unicredit.it


chains to Swisscom:

https://crt.sh/?id=5982951*.*.int.swisscom.ch





Internals TLD:


chains to Baltimore CyberTrust Root (DigiCert):

https://crt.sh/?id=33626750a1.verizon.test


I believe this cert is presently untrusted by Mozilla due to revocation 
of the relevant subCA:

https://crt.sh/?id=33123653DAC38997VPN2001A.trmk.corp


chains to Certplus (DocuSign):

https://crt.sh/?id=42475510naccez.us.areva.corp


I believe these presently lack an unrevoked, unexpired trust path in 
Mozilla:

https://crt.sh/?id=10621703collaboration.intra.airbusds.corp
https://crt.sh/?id=48726306zdeasaotn01.dsmain.ds.corp

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

Re: Certificate with invalid dnsName

[Charles Reiss via dev-security-policy]

On 07/19/2017 06:03 PM, Tom wrote:

Following that discovery, I've search for odd (invalid?) DNS names.
Here is the list of certificated I've found, it may overlap some 
discovery already reported.
If I'm correct, theses certificate are not revoked, not expired, and 
probably trusted by Mozilla (crt.sh issuer are marked trusted by 
Mozilla, but not all).



[snip]

Some additional problematic certs:

chains to Swisscom:
https://crt.sh/?id=175444569  wxadm.swissucc.local

chains to CATCert, notBefore in 2017:
https://crt.sh/?id=98706307   maritim4.mmaritim.local

chains to PROCERT, notBefore in 2017:
https://crt.sh/?id=175466182  fospuca.local

chains to Baltimore Cybertrust Root (DigiCert):
https://crt.sh/?id=12344381   lorweb.local

chains to Baltimore Cybertrust Root (DigiCert), notBefore in 2017:
https://crt.sh/?id=175469208  skbfep01.justica.local
https://crt.sh/?id=175469209  energy.ctd  and  pt

chains to QuoVadis, notBefore in 2017:
https://crt.sh/?id=175466199  devsrv.pe.siemens.info-com  (swapped -/.)

chains to DocuSign, notBefore in 2017:
https://crt.sh/?id=99149574   "www.immonotaireargus.com " (trailing space)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: TunRootCA2 root inclusion request

[Charles Reiss via dev-security-policy]

On 07/19/2017 05:10 AM, Aaron Wu wrote:

- Tunisian Server Certificate Authority - TunServerCA2


https://crt.sh/?id=79470561=cablint is a certificate for the 
internal name 'adv-mail.calladvance.local' issued by this CA with a 
notBefore of 2017.

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

Re: TunRootCA2 root inclusion request

[Charles Reiss via dev-security-policy]

On 07/19/17 05:10, Aaron Wu wrote:

- Tunisian Server Certificate Authority - TunServerCA2



https://crt.sh/?id=21813439 is a certificate issued by this CA which has 
a domain name in the common name but only an email address in the SAN. 
(The certificate has TLS server/client usage EKUs.)



https://crt.sh/?id=99182607 is a revoked certificate issued by this CA 
which has a domain name in the common name which does not match the 
domain name in the SAN, which is for a different TLD. (A new certificate 
with both names in SANs, https://crt.sh/?id=99462700 , has a notBefore 
which appears to have around the same timestamp as the revocation.)



https://crt.sh/?id=15126121 is an expired certificate (notBefore March 
2016; notAfter March 2017) issued by this CA which has a wildcard name 
in the common name while the SAN contains specific domain names that 
would be covered by the wildcard only.



https://crt.sh/?id=10975511 is an expired certificate with a notBefore 
of Oct 2015 and notAfter of Oct 2016 issued by this CA with an iPAddress 
SAN of 127.0.0.1. (I believe that by 2014, the BRs prohibited issuing 
internal name certs with validity past November 2015.)

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

Re: Certificate with invalid dnsName issued from Baltimore intermediate

[Charles Reiss via dev-security-policy]

On 07/18/2017 11:57 AM, Hanno Böck wrote:

More dotdot-certificates:

[snip]

via searching censys.io:

https://crt.sh/?id=174803642
for *..syntaxafrica.com
Issued by GoDaddy in 2016; expires later this year, but revoked (CRL 
timestamp says a few days after issuance)


https://crt.sh/?id=38662560
for *usmc..afpimsstaging.mil
Issued by U.S. Government in 2012; expired 2015

I also some old internal name certificates:

https://crt.sh/?id=39441152
for autodiscover.eat...ltransport.local
Issued by GoDaddy in 2012; expired 2015

https://crt.sh/?id=39333847
for autodiscover.jgexchange2.bellgibfamily.local
Issued by GoDaddy in 2012; expired 2015
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: March 2016 CA Communication Responses

[Charles Reiss]

On 04/13/16 20:32, Kathleen Wilson wrote:

All,

I have added links to reports of the responses to the March 2016 CA
Communication survey:

https://wiki.mozilla.org/CA:Communications#March_2016_Responses


For question 1a, TeliaSonera indicated "2015 Oct 20", but the following 
SHA-1 server certificate has a notBefore of 17 March 2016 and appears to 
chain to TeliaSonera Root v1:

https://censys.io/certificates/ff7f4a0f23205127347018555628b05d11a355ed92e9aa59d5eabda750f0f622




Please keep in mind that the responses are considered preliminary and
may be changed until April 22, 2016. And remember that up until about
2010, some CAs were issuing 10 year TLS/SSL certificates, so this may
cause some consternation regarding responses to ACTION #1b.

Also, I still need to add the new "ACTION 1a TEXT INPUT" and "ACTION
1b TEXT INPUT" data to the reports.

Thanks, Kathleen



___
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

[Charles Reiss]

On 03/30/16 20:53, 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).

Is issuing non-SHA-1 certificates proscribed by any of these national
schemes? Have any of these national schemes not contemplated a
transition away from SHA-1 for many years?

> 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.

I'd guess that many non-browser users (e.g. curl/wget on many Linux
distros) of Mozilla's root store will continue to accept SHA-1 server
certificates and/or OCSP responses for quite a while after Mozilla's
browsers start rejecting them.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Drafting Q1 2016 CA Communication

[Charles Reiss]

On 03/22/16 16:33, kwil...@mozilla.com wrote:
> The following 'ACTION #1c' has been added to the communication, which
> is here: https://wiki.mozilla.org/CA:Communications#March_2016 and
> click on "Link to DRAFT of March 2016 CA Communication".

With the current wordings of #1a and #1b, if
- a CA has both the email and websites trust bits; and
- their last SHA-1 S/MIME certificate {was issued,expires} later than
their last SHA-1 TLS server certificate,
then they should give the TLS date. Is this intentional?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Drafting Q1 2016 CA Communication

[Charles Reiss]

On 03/16/16 17:48, kwil...@mozilla.com wrote:
> On Wednesday, March 16, 2016 at 6:03:26 AM UTC-7, Jakob Bohm wrote:
>> On 16/03/2016 00:27, Charles Reiss wrote:
>>> On 03/15/16 22:43, kwilson wrote:
>>>> 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 and S/MIME 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 and S/MIME certificates chaining up to your included
>>>> root certificates are no longer being issued. 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. (Required)
>>> 
>>> For reasons discussed in thread on BR scope here (that
>>> restrictions from certificate contents won't be effective against
>>> a chosen-prefix collision attack), I was hoping that Mozilla
>>> would ask whether CAs would continue issuing any SHA-1
>>> certificates, regardless of suitability for TLS or S/MIME (except
>>> those that chain through technically constrained subCAs issued
>>> before 2016). But perhaps that needs to be done in context of
>>> more expansive improvements to Mozilla's policies.
>>> 
> 
> 
> Should we add a question to the survey about each CA's plans for
> issuance of SHA-1 based certificates other than TLS/SSL and S/MIME
> certificates that chain up to their included root certs?

If Mozilla intends to use the survey to inform its decision about
whether to distrust all SHA-1 certificates earlier than the current Jan
2017 date, yes.

>> 
>> I would suggest that in order to make themselves compliant, CAs
>> should be allowed to internally generate and issue a very limited
>> number of new technically constrained SHA-1 subCAs, where extreme
>> precautions are taken to ensure the internal data to be signed does
>> not facilitate SHA-1 collisions.   The major CAs probably did that
>> before the 1/1/2016 deadline, but some of the smaller CAs may have
>> not gotten that done yet.
>> 
> 
> 
> Are you saying that CAs should be able to issue SHA-1 intermediate
> certificates that are capable of issuing TLS/SSL certificates but are
> technically constrained via name constraints to certain domains?

I assume the idea is that the intermediates are technically constrained
from signing TLS or S/MIME certificates at all; for example, with an
extendedKeyUsage extension containing only code signing.

> 
> Thanks, Kathleen
> 

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

Re: Drafting Q1 2016 CA Communication

[Charles Reiss]

On 03/15/16 22:43, kwil...@mozilla.com wrote:
> On Monday, March 14, 2016 at 5:28:32 PM UTC-7, Charles Reiss wrote:
>>> 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. Check your systems
>>> and those of your subordinate CAs to ensure that SHA-1
>>> certificates chaining up to your included root certificates are
>>> no longer being issued. Please enter the last date that a SHA-1
>>> certificate was issued that chained up to your root
>>> certificate(s) included in Mozilla's program. (Required)
>> 
>> Mozilla should make clear how this question should be answered
>> with respect to issuance of: a) SHA-1 subCAs which are constrained
>> by EKU to not issue TLS server or email certs (e.g. for code
>> signing); b) SHA-1 end-entity certificates which are constrained by
>> EKU to not be for TLS servers or email certs but whose issuing
>> subCA is not so constrained; c) SHA-1 end-entity certificates which
>> are not constrained by EKU but lack a common name or SAN which can
>> be used a server name or email address; and d) SHA-1 end-entity
>> certificates whose parent CA is constrained by EKU to not be for
>> TLS server or email certs;
>> 
>> The question as written would seem to me to apply to all of these
>> (since "SHA-1 certificates chaining up to your included root
>> certificates" is not qualified), but it seems, from inclusion
>> request discussion, that CAs tend to think that "out of scope"
>> certificates need not be mentioned.
>> 
> 
> Does the following text clear it up?
> 
> 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 and S/MIME
> 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 and S/MIME certificates chaining up
> to your included root certificates are no longer being issued. 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. (Required)

For reasons discussed in thread on BR scope here (that restrictions from
certificate contents won't be effective against a chosen-prefix
collision attack), I was hoping that Mozilla would ask whether CAs would
continue issuing any SHA-1 certificates, regardless of suitability for
TLS or S/MIME (except those that chain through technically constrained
subCAs issued before 2016). But perhaps that needs to be done in context
of more expansive improvements to Mozilla's policies.

>> [snip]
>>> ACTION #6: All certificates that directly or transitively chain
>>> to your root certificate(s) included in Mozilla's CA Certificate
>>> Program must comply with Mozilla's CA Certificate Policy. This
>>> includes test certificates.
>>> 
>>> Review your policies, procedures, and auditing about issuance of
>>> test certificates, what domain names may be used in test
>>> certificates, and the domain verification procedures that must be
>>> followed for test certificates.
>>> 
>>> [TBD] What else should we say here? -- What sort of responses to
>>> we want from CAs? -- Rules about testing and test certs (per
>>> Symantec incident) -- What sorts of things do we want to make
>>> sure CAs do and don't do regarding testing? (Required)
>> 
>> Maybe a reminder that test certificates Mozilla expects test 
>> certificates to follow the domain validation procedures in the
>> CA's CP/CPS (that Mozilla presumably reviewed) and not just be
>> issued in compliance with the BRs per se?
> 
> 
> How about the following?

This seems to address that.

My suspicion is that CAs generally think their test certificates comply
with Mozilla's policy in terms of certificate contents, so maybe that is
not the right thing to emphasize? My guess is that the real problems are
ad-hoc and/or unpublished policies for how compliance is to be achieved.
I think this is clearly prohibited by Mozilla's policies (which, e.g.,
require CAs notify Mozilla when "its policies and business practices
change in regards to verification procedures for issuing certificates").

> ACTION #6: All certificates that directly or transitively chain to
> your root certificates included in Mozilla's CA Certificate Program
> must comply with Mozilla's CA Certificate Policy. This includes test
> certificates.
> 
&g

Re: Drafting Q1 2016 CA Communication

[Charles Reiss]

On 03/10/16 23:43, kwil...@mozilla.com wrote:
[snip]
> Regards,
> 
> Kathleen Wilson Mozilla CA Program Manager
> 
> 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. Check your systems and those of
> your subordinate CAs to ensure that SHA-1 certificates chaining up to
> your included root certificates are no longer being issued. Please
> enter the last date that a SHA-1 certificate was issued that chained
> up to your root certificate(s) included in Mozilla's program.
> (Required)

Mozilla should make clear how this question should be answered with
respect to issuance of:
a) SHA-1 subCAs which are constrained by EKU to not issue TLS server or
email certs (e.g. for code signing);
b) SHA-1 end-entity certificates which are constrained by EKU to not be
for TLS servers or email certs but whose issuing subCA is not so
constrained;
c) SHA-1 end-entity certificates which are not constrained by EKU but
lack a common name or SAN which can be used a server name or email
address; and
d) SHA-1 end-entity certificates whose parent CA is constrained by EKU
to not be for TLS server or email certs;

The question as written would seem to me to apply to all of these (since
"SHA-1 certificates chaining up to your included root certificates" is
not qualified), but it seems, from inclusion request discussion, that
CAs tend to think that "out of scope" certificates need not be mentioned.

[snip]
> ACTION #6: All certificates that directly or transitively chain to
> your root certificate(s) included in Mozilla's CA Certificate Program
> must comply with Mozilla's CA Certificate Policy. This includes test
> certificates.
> 
> Review your policies, procedures, and auditing about issuance of test
> certificates, what domain names may be used in test certificates, and
> the domain verification procedures that must be followed for test
> certificates.
> 
> [TBD] What else should we say here? -- What sort of responses to we
> want from CAs? -- Rules about testing and test certs (per Symantec
> incident) -- What sorts of things do we want to make sure CAs do and
> don't do regarding testing? (Required)

Maybe a reminder that test certificates Mozilla expects test
certificates to follow the domain validation procedures in the CA's
CP/CPS (that Mozilla presumably reviewed) and not just be issued in
compliance with the BRs per se?

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

Re: More SHA-1 certs

[Charles Reiss]

On 03/03/16 19:48, Ryan Sleevi wrote:
> On Thursday, March 3, 2016 at 9:20:07 AM UTC-8, Andrew Ayer wrote:
>> It's also troubling that a CA may be allowed to continue issuing 
>> non-serverAuth certs with SHA-1 from an issuer that is also used
>> for serverAuth certs.  Again, a collision attack could be used to
>> forge a trusted serverAuth cert.
>> 
>> I urge that this hole be fixed in both Mozilla policy and the BRs,
>> not just by clarifying the cert/pre-cert equivalence, but also by
>> forbidding an issuer that is trusted for serverAuth from signing
>> _anything_ with SHA-1.
> 
> A resounding +1 to this. This goes back to the core goal - if a
> certificate has id-kp-serverAuth / is in scope for the BRs, the only
> way to make a reasonable argument about the cryptographic operations
> is if _everything_ issued by that CA is seen in scope.
> 
> This is not just a matter for SHA-1; consider an intermediate with
> id-kp-serverAuth and id-kp-emailProtection. If, in the issuance of
> S/MIME certificates, the CA leaves off the EKU from the leaf, and
> issues a commonName of "example.com", then that certificate - though
> intended for email - can now be used for TLS authentication. This is
> wholly independent of SHA-1 deprecation.

And I'd guess that (based on lack of EKU and existence of rfc822Name
SAN) this SHA-1 certificate is an example of precisely that problem:
https://crt.sh/?id=15019496
(used in the wild for a TLS server as of this writing:
https://censys.io/ipv4/194.145.239.217)


> 
> For this reason, I'm a strong supporter in mandating that the scope
> of Mozilla's policies - and, more importantly, the expectation of BR
> compliance - extends to include _all_ certificates issued from an
> intermediates capable of causing TLS certificate issuance, even if
> those leaves are not intended for TLS.
> 

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

Re: Proposed limited exception to SHA-1 issuance

[Charles Reiss]

On 02/23/16 18:57, Gervase Markham wrote:
[snip]
> Symantec may issue certificates to Worldpay if the following things are
> true:

Based on what's happened with MD5 certificates, it seems the main risk
of harm comes from something like a chosen-prefix collision attack using
a specially constructed CSR. In this case, the serial number of the
resulting colliding certificate can be forged, so Mozilla's
revocation/OneCRL requirement wouldn't seem to do much unless the OneCRL
entries are keyed on the tbsCertificate SHA1 hash or similar (and not
the issuer+serial number or the whole certificate hash).

If Mozilla is to allow this SHA1 issuance, it should also consider
requiring steps to limit the impact of such attacks, such as one or more of:

- Issuing the certificates from a subCA with a pathlen constraint that
prevents that subCA from signing subsubCA certificates, which I gather
is the already the case for most (all?) of Symantec's subCAs that
directly issue TLS server certificates.

- Including >80 bits of entropy in the serial numbers of these
certificates. (The BRs recommend but do not require 20 bits, and
Symantec does not follow this recommendation under some of their subCAs:
https://crt.sh/?cablint=38=1559)

- Issuing the certificates via an internally operated (SHA-1) subCA that
is technically constrained within the meaning of Mozilla's policy.

___
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

[Charles Reiss]

On 02/18/16 21:40, Erwann Abalea wrote:
> Bonsoir,
> 
> Le mercredi 10 février 2016 00:15:11 UTC+1, Charles Reiss a écrit :
>> On 02/09/16 20:07, Kathleen Wilson wrote:
>>> This request by DocuSign (OpenTrust/Keynectis/Certplus) is to
>>> include the following root certificates, turn on the Websites and
>>> Email trust bits for all of them, and enable EV treatment for all
>>> of them. These new certs will eventually replace the 'Certplus
>>> Class 2' root certificate that was included via Bugzilla Bug
>>> #335392. + Certplus Root CA G1 - (SHA512, RSA4096) + Certplus
>>> Root CA G2 - (SHA384, ECC) + OpenTrust Root CA G1 - (SHA256,
>>> RSA4096) + OpenTrust Root CA G2 - (SHA512, RSA4096) + OpenTrust
>>> Root CA G3 - (SHA384, ECC)
>>> 
>>> Previously the company was known as Keynectis, with the Certplus
>>> and OpenTrust brands, issuing certs to public or private
>>> corporations, associations.
>>> 
>>> Ownership changed November 3, 2015, from Keynectis to DocuSign
>>> France, which was acquired by DocuSign Inc. The root keys
>>> remained at the same physical location operated by the same team.
>>> During the transfer of activity, all past agreements/contracts
>>> and so on remain available. People linked to this activity were
>>> also transferred to the new company.
>>> 
>>> The request is documented in the following bug: 
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1025095
>>> 
>>> 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=8692112
>>> 
>>> Noteworthy points:
>>> 
>>> * The primary documents are the RCA CP, SSL CP, and EV CPS.
>>> Documents are provided in French and some are translated into
>>> English.
>>> 
>>> Document Repository (French): http://www.OpenTrust.com/PC 
>>> Document Repository (English): 
>>> https://www.opentrustdtm.com/security-policies/?lang=en RCA -
>>> Root Certificate Authorities - CP (English): 
>>> https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_RCA-Program_OpenTrust_CP-v-1.2s2.pdf
>>
>>
>>
>>> My reading of section 8.1 of the CP is that if CA is
>> - _not_ technically constrained (as defined by Mozilla); and - not
>> "issuing SSL certificates" (e.g. a CA lacking any EKU or name
>> constraints that only issues certificates to individuals), then, it
>> can be audited only by auditors who do not meet Mozilla's
>> definition of an independent auditor. (8.2 allows internal auditors
>> to be only "sufficiently organizationally separated from that
>> entity to provide an unbiased, independent evaluation", which seems
>> like it could include a CA employee.) Is this correct?
> 
> For CAs not issuing TLS certificates, an internal audit is performed,
> as permitted by Mozilla's definition of an independent auditor. See
> Mozilla Inclusion Policy version 2.2, items 11, 12, 13, and 14.

Mozilla's definition of independent auditor requires that the auditor "
not [be] affiliated with the CA as an employee or director". I assume
that this will be the case for subCAs for which an internal audit is
performed by virtue of the audit being performed employees of the parent
CA, a different company.

I don't believe having CAs audit their unconstrained subCAs is within
the spirit of Mozilla's policy (since a sufficiently non-compliant subCA
is an existential risk to the parent CA) though it is probably
technically in conformance.

I assume you believe the internal audit fits the third option of item
14's second requirement: "the party is bound by law, government
regulation, and/or a professional code of ethics to render an honest and
objective judgement regarding the CA" (since I imagine you aren't going
to be disclosing your financial relationship with external subCAs). Can
you identify what law, regulation, or code of ethics is involved?

[snip]
> 
>> Section 9.3.3 of this CP states in part: "PKI components must not
>> disclose certificate or certificate-related information to any
>> third party unless authorized by this policy" while section 9.4.3
>> states: "Any and all information within a certificate is inherently
>> public information and shall not be considered confidential
>> information."
>> 
>> What is the 'certificate information' contemplated by section 9.3.3
>> that is not contained within a certificate?
> 
> Certificate-related information that are protected by privacy laws,
> such as telephone numbers, copies of ID cards, passwords or PIN
> numbers exchanged between the customer and the CA/RA. Event logs are
> also confidential.

In the event of serious certificate misissuance, what information about
those certificates and how they were issued will DocuSign be able to
share with the public?

___
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

[Charles Reiss]

On 02/09/16 20:07, Kathleen Wilson wrote:
> This request by DocuSign (OpenTrust/Keynectis/Certplus) is to include
> the following root certificates, turn on the Websites and Email trust
> bits for all of them, and enable EV treatment for all of them. These new
> certs will eventually replace the ‘Certplus Class 2’ root certificate

These certificates chain to the 'Certplus Class 2' root and contain a
trailing space in one of their dNSName SANs:

notBefore in 2016:
https://crt.sh/?id=12994171=cablint
notBefore in 2015:
https://crt.sh/?id=10643272=cablint
https://crt.sh/?id=9651778=cablint



> that was included via Bugzilla Bug #335392.
> + Certplus Root CA G1 - (SHA512, RSA4096)
> + Certplus Root CA G2 - (SHA384, ECC)
> + OpenTrust Root CA G1 - (SHA256, RSA4096)
> + OpenTrust Root CA G2 - (SHA512, RSA4096)
> + OpenTrust Root CA G3 - (SHA384, ECC)
> 
> Previously the company was known as Keynectis, with the Certplus and
> OpenTrust brands, issuing certs to public or private corporations,
> associations.
> [snip]

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

Re: A-Trust Root Renewal Request

[Charles Reiss]

On 02/12/16 14:26, Christoph Klein wrote:
> Dear All!
> 
> Thank you for contributing in our discussion and illustrate some
> existing problems with our certificates. I would like to address the
> stated points seperatley.
[snip]
> * 20 Bits of Entropy: the Serialnumber included in the Subject of our
> SSL - certificatges is randomly generated

When you reissue a certificate for the same subject, you appear to reuse
the same serial number (see, e.g., https://crt.sh/?id=12740856 and
https://crt.sh/?id=1659927). This makes sense for a subject's serial
number, but means that the random value does not serve the purpose of
making chosen-prefix collision attacks more difficult when a subscriber
requests a renewed certificate.

Also, in EV certificates, this subject serialNumber field number field
represents the registration number of the subject, so those certificates
do not seem to have added entropy at all.

> 
> * V Clause (X): We analyzed this problem and found an issue, where
> the variable wasn't transfered into the final certificate. This bug
> has been around since our first issued EV certificate and wasn't
> noticed until now. The problem is fixed, new certificates will
> replace the x with the proper letter.

Given that every EV certificate you issued had this error, and you have
been issuing EV certificates since at least 2013 (from your old root),
how was this error not detected by the self-audit you are required to
perform of 'a randomly selected sample of at least three percent of the
EV Certificates'?

[snip]
___
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

[Charles Reiss]

On 02/09/16 20:07, Kathleen Wilson wrote:
> This request by DocuSign (OpenTrust/Keynectis/Certplus) is to include
> the following root certificates, turn on the Websites and Email trust
> bits for all of them, and enable EV treatment for all of them. These new
> certs will eventually replace the ‘Certplus Class 2’ root certificate
> that was included via Bugzilla Bug #335392.
> + Certplus Root CA G1 - (SHA512, RSA4096)
> + Certplus Root CA G2 - (SHA384, ECC)
> + OpenTrust Root CA G1 - (SHA256, RSA4096)
> + OpenTrust Root CA G2 - (SHA512, RSA4096)
> + OpenTrust Root CA G3 - (SHA384, ECC)
> 
> Previously the company was known as Keynectis, with the Certplus and
> OpenTrust brands, issuing certs to public or private corporations,
> associations.
> 
> Ownership changed November 3, 2015, from Keynectis to DocuSign France,
> which was acquired by DocuSign Inc. The root keys remained at the same
> physical location operated by the same team. During the transfer of
> activity, all past agreements/contracts and so on remain available.
> People linked to this activity were also transferred to the new company.
> 
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1025095
> 
> 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=8692112
> 
> Noteworthy points:
> 
> * The primary documents are the RCA CP, SSL CP, and EV CPS. Documents
> are provided in French and some are translated into English.
> 
> Document Repository (French): http://www.OpenTrust.com/PC
> Document Repository (English):
> https://www.opentrustdtm.com/security-policies/?lang=en
> RCA - Root Certificate Authorities - CP (English):
> https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_RCA-Program_OpenTrust_CP-v-1.2s2.pdf


My reading of section 8.1 of the CP is that if CA is
- _not_ technically constrained (as defined by Mozilla); and
- not "issuing SSL certificates"
(e.g. a CA lacking any EKU or name constraints that only issues
certificates to individuals), then, it can be audited only by auditors
who do not meet Mozilla's definition of an independent auditor. (8.2
allows internal auditors to be only "sufficiently organizationally
separated from that entity to provide an unbiased, independent
evaluation", which seems like it could include a CA employee.) Is this
correct?


Section 9.3.1 of this CP suggests that "audit results and reports" are
confidential information, which seems to be at odds with Mozilla's
public attestation requirement.


Section 9.3.3 of this CP states in part:
"PKI components must not disclose certificate or certificate-related
information to any third party unless authorized by this policy"
while section 9.4.3 states:
"Any and all information within a certificate is inherently public
information and shall not be considered confidential information."

What is the 'certificate information' contemplated by section 9.3.3 that
is not contained within a certificate?

> 
> SSL CP (French):
> https://www.opentrustdtm.com/wp-content/uploads/2015/11/OpenTrust_DMS_PC-Certificats-OpenTrust-SSL-RGS-et-ETSI-V15.pdf
> 
> EV CPS (English):
> https://www.opentrustdtm.com//wp-content/uploads/2015/03/OpenTrust_DMS_EV_SSL_CA_Certification_Practice_Statement_2014_12_18s.pdf
> 
> 
> 
> * CA Hierarchy: These new root certificates have cross-signed with the
> currently-included ‘Certplus Class 2’ root certificate which expires in
> 2019.
> 
> Certplus Root CA G1 issued:
> - EV CA: KEYNECTIS Extended Validation CA
> 
> Certplus Root CA G2 issued:
> - EV CA: KEYNECTIS Extended Validation CA
> 
> OpenTrust Root CA G1 issued:
> - EV CA: KEYNECTIS Extended Validation CA
> - AATL CA: OpenTrust CA for AATL G1
> 
> OpenTrust Root CA G2 issued:
> - EV CA: KEYNECTIS Extended Validation CA
> - AATL CA: OpenTrust CA for AATL G2
> 
> OpenTrust Root CA G3 issued:
> - EV CA: KEYNECTIS Extended Validation CA
> - AATL CA: OpenTrust CA for AATL G3
> 
> * This request is to turn on the Websites and Email trust bits, and
> enable EV treatment for all 5 of these root certificates.
> 
> Translation of sections of the SSL CP:
> 
> 4.1 Certificate Application
> Sections 4.1, 4.2, 4.3 and 4.4 specify the requirements for an initial
> application for certificate issuance. Sections 4.6, 4.7 and 4.8 specify
> the requirements for certificate renewal.
> 4.1.1Who Can Submit a Certificate Application
> A certificate request is addressed by TC (Technical Contact) or an SSL
> Administrator to RA.
> 4.1.2Enrollment Process and Responsibilities
> The complete application form, signed and dated, shall be addressed to
> RA by CT or SSL Administrator.
> 
> 4.1.2.1 Certificate non RGS: DV (Domain Validated Certificate)
> The following information must be included in the SSL certificate request:
> - The certificate request is signed by the TC (depending on the origin
> of the request), and 

Re: A-Trust Root Renewal Request

[Charles Reiss]

On 02/09/16 01:22, Kathleen Wilson wrote:
> This request is to include the ‘A-Trust-Root-05’ root certificate, turn
> on the Websites trust bit, and enable EV treatment. This new root
> certificate will replace the ‘A-Trust-nQual-03’ root certificate that
> was included via Bugzilla Bug #530797. The ‘A-Trust-nQual-03’ root
> certificate expired, so it was removed via Bugzilla Bug #1204997.
[snip]

> * CA Hierarchy: This root has internally-operated subordinate CAs:
> - a-sign-SSL-05 (http://www.a-trust.at/certs/a-sign-ssl-05.crt)

These certificates were issued last year for the internal name 'TRUE'
and are valid until at least 2018 (well past the deadline for internal
names under the BRs):
https://crt.sh/?dnsname=True=5662

These were issued last year for the internal name '1' and are valid
until at least 2017 (still well past the deadline):
https://crt.sh/?dnsname=1=5662

From those internal name certificates above, these certificates are
valid from 2015 until 2020, which is longer than the 39 months allowed
under the BRs:
https://crt.sh/?id=8991758=cablint
https://crt.sh/?id=9123894=cablint

This certificate was issued last year for the internal name 'BSB-oenb'
and is valid from 2015 until 2020:
https://crt.sh/?id=10540258=cablint

These certificates also seem to lack the at least 20 bits of entropy in
the certificate serial number that the BRs recommend in section 7.1.

> - a-sign-SSL-EV-05 (http://www.a-trust.at/certs/a-sign-ssl-ev-05.crt)

CT appears to know about several other subCAs; see child CAs here:
https://crt.sh/?caid=5661

My assumption is that the other subCAs are not supposed to issue SSL
certificates however, they still need to be in scope as they do not
appear technically constrained from doing so (e.g. by extendedKeyUsage).
(However, it appears that the prior root's subCA
a-sign-corporate-light-03 issued TLS server certificates (e.g.
https://crt.sh/?id=5669744=cablint) and it is presumably similar to
a-sign-corporate-05.)



> 
> * This request is to turn on the Websites trust bit, and enable EV
> treatment.
> 
> Translation of EV SSL CPS sections 3.1.7, 3.1.8, and 3.1.9:
> https://bug1092963.bugzilla.mozilla.org/attachment.cgi?id=8584406
> 
> 3.1.7 Authentication of organisations
> When ordering an a.sign SSL EV certficate, the domain and organisation
> has to be verified. If the ordering entity is registered in either the
> austrian commercial register or the European Business Register (EBR),
> A-Trust verifies the existence using the online - database of those
> registers. The registration number has to be inlcuded in the request.
> The physical address is also verified using the offical register. If not
> applicable, the check is performed using a duplicate of a document that
> confirms the organisations existence. Examples for such documents are
> extracts from legal registers or databases of trusted third parties.
> The checks are performed according to the requirements in EV-GL
> (guidelines v1.2, CAB Forum), section 10.
> 
> In case an a.sign SSL EV certificate is order, additional information
> has to be gathered:
> # confirmation issued by the bank of the ordering organisation,
> confirming the existance of an account related to the organisation
> # annual statement of the organisation, verified by a certified accountant
> # if an exchange embargos exist (inqury at responsible entity in the
> applicants country through A-Trust)
> # verification of the physical address. If the address provided in the
> legal register used for verification of the organisation is also stated
> in the annual statement gathered in point 2, the physical address is
> considered correct. If these requirements are not met, verification can
> only be achieved through a check on location. Possible costs of this
> check are charged to the applicant. Further information can be found at
> EV-GL, section 10.4.1.
> 
> If an entire obtaining of all required information is not possible
> within a reasonable amount of time, the application is rejected and the
> applicant will be informed.
> 
> 3.1.8 Check of Domain or IP Address
> The holder of a domain is verified using the databases provided by the
> applicable authority (such as www.nic.at, www.denic.de,...).
> The use of IP adresses in EV certficates is not permitted.
> 
> 3.1.9 Authentication of individuals
> The individuals, who are audited in the process of issuing an a.sign SSL
> EV certificate are
> # the domain owner
> and, if the domain order is acting in the name of an organisation
> # an organisational responsible person, that is allowed to sign in the
> ogranisations name and confirms the correctness of the application
> The people that are mentioned in the application have to provide an
> identification document (i.e. passport).
> If the organisational responsible person is not listed in the used
> register, additional confirmation of his status has to be provided (i.e.
> a certificate of authority).
> 
> * Root Certificate Download URL:
> 

Re: More SHA-1 certs

[Charles Reiss]

On 02/05/16 20:13, martin.suc...@gmail.com wrote:
> Here's a list of all certificates with SHA-1 signatures and notBefore >= 
> 2016-01-01, logged in the Certificate Transparency Log:
> https://crt.sh/?cablint=211=2016-01-01

Some notes on how these look as of now. The listed subCA CNs are:
- DOD CA-28
- DOD CA-27

These chain to DST ACES CA X6, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c21 and
https://cabforum.org/pipermail/public/2016-February/006696.html


- Intel External Basic Issuing CA 3A

These chain through a technically constrained subordinate CA
https://crt.sh/?id=1250505


- Symantec Private SSL SHA1 CA

These chain to the 1024-bit VeriSign roots 'Class 3 Public Primary
Certification Authority' and 'Class 3 Public Primary Certification
Authority - G2' which are no longer included in Mozilla's root program.

Curiously, the similar COMODO CA 'COMODO Domain Validation Legacy Server
CA 2' (chains to retired root 'UTN - DATACorp SGC') appears to be
exempted from listing? (example cert:
https://crt.sh/?id=12584167=cablint)


- VeriSign Class 3 Secure Server CA - G3
- VeriSign Class 3 International Server CA - G3

I believe these are the certs at
https://cabforum.org/pipermail/public/2016-January/006519.html or
precertificates for them.

- RSA Corporate Server CA v2
- DnB NOR ASA PKI Class G
- Shared Business CA 3
- TI Trust Technologies Global CA
- Postecom CS3
- Aetna Inc. Certificate Authority
- SHECA
- AC Infrastructure
- YourNet SSL for business
- Verizon Public SureServer CA G14-SHA1

These have been mentioned here previously.



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

Re: More SHA-1 certs

[Charles Reiss]

On 02/05/16 21:14, Ben Wilson wrote:
> Aren't all of these CA certificates?

The links in the '#' column are to lists of BR-noncompliant
certificates; the links in the 'Issuer Name' column are to information
about the issuing DN+public key of those certificates.

> 
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of martin.suc...@gmail.com
> Sent: Friday, February 5, 2016 1:13 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: More SHA-1 certs
> 
> Here's a list of all certificates with SHA-1 signatures and notBefore >=
> 2016-01-01, logged in the Certificate Transparency Log:
> https://crt.sh/?cablint=211=2016-01-01
> ___
> 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: SHA1 certs issued this year chaining to included roots

[Charles Reiss]

On 01/19/16 01:49, Charles Reiss wrote:
> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this 
> year
> which chain to root CAs in Mozilla's program:
[snip]

and even more, from different subCAs than have come up yet:

- https://crt.sh/?id=12501241=cablint -- Baltimore CyberTrust Root
[DigiCert] via Verizon Public SureServer CA G14-SHA1

- https://crt.sh/?id=12309564=cablint -- Baltimore CyberTrust Root
[DigiCert] via TI Trust Technologies Global CA

- https://crt.sh/?id=12501254=cablint -- RSA Security 2048 V3 via
RSA Corporate CA v2 via RSA Corporate Server CA v2

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

Re: SHA1 certs issued this year chaining to included roots

[Charles Reiss]

On 01/19/16 11:49, Jakob Bohm wrote:
> On 19/01/2016 02:49, Charles Reiss wrote:
>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this 
>> year
>> which chain to root CAs in Mozilla's program:
>>
>> - https://crt.sh/?id=12089828 -- chains to Baltimore CyberTrust Root 
>> [DigiCert]
>> via subCA "Eurida Primary CA" via subCA "DnB NOR ASA PKI Class G"
>>
>> Also, the OCSP responder for this certificate appears to not include a
>> nextUpdate field.
>>
> 
> Does the OCSP spec say what "no nextUpdate" should default to?  Like maybe
> "dontcache, expires instantly".
> 
>>
>> - https://crt.sh/?id=12090324 -- chains to Security Communication RootCA1
>> [SECOM] via subCA "YourNet SSL for business"
>> 
>> Also, this certificate is also missing OCSP information and appears to be 
>> being
>> served without OCSP stapling support.
>>
> 
> If there is no OCSP, it obviously cannot be stapled.

The CA/Browser forum BRs contemplate OCSP stapling without an OCSP responder
being listed in the certificate in section 7.1.2.2.c ("The HTTP URL of  the
Issuing CA’s OCSP responder MAY be omitted, provided that the Subscriber
“staples” the OCSP response for the Certificate in its TLS handshakes
[RFC4366].") I assume the idea is that the OCSP responder URL would be manually
configured in the server and that this would make the certificate slightly 
smaller.

> In addition to the above, note that *code signing* and *document
> signing* certificates may be issued after the deadline for SSL SHA-1
> certificates, because some important relying party software cannot be
> upgraded to support modern signature hash algorithms (most notably
> Microsoft platforms released before 2009).
> 
> Such compatibility SHA-1 certificates typically have to chain to
> existing roots too (again because of relying party software
> limitations).

I would hope such issuance is occurring under technically constrained subCAs so
that a Flame-style chosen-prefix collision attack cannot result in a rogue
certificate that Mozilla would trust for TLS servers so long as Mozilla does not
disable SHA-1 certificates entirely.

> 
> 
> Enjoy
> 
> Jakob

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

SHA1 certs issued this year chaining to included roots

[Charles Reiss]

Via censys.io, I found a couple SHA-1 certs with notBefore dates from this year
which chain to root CAs in Mozilla's program:

- https://crt.sh/?id=12089828 -- chains to Baltimore CyberTrust Root [DigiCert]
via subCA "Eurida Primary CA" via subCA "DnB NOR ASA PKI Class G"

Also, the OCSP responder for this certificate appears to not include a
nextUpdate field.


- https://crt.sh/?id=12090324 -- chains to Security Communication RootCA1
[SECOM] via subCA "YourNet SSL for business"

Also, this certificate is also missing OCSP information and appears to be being
served without OCSP stapling support.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SHA1 certs issued this year chaining to included roots

[Charles Reiss]

On 01/19/16 03:37, Charles Reiss wrote:
> On 01/19/16 03:23, Kurt Roeckx wrote:
>> On Tue, Jan 19, 2016 at 01:49:21AM +, Charles Reiss wrote:
>>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this 
>>> year
>>> which chain to root CAs in Mozilla's program:
>>
>> I also have some from C=US,O=VeriSign\, Inc.,OU=VeriSign Trust
>> Network,OU=Terms of use at https://www.verisign.com/rpa
>> (c)10,CN=VeriSign Class 3 International Server CA - G3".  I'm not
>> sure that CA is still included, but I think it it.
>>
>> It includes certificates like C=US,ST=California,L=Mountain
>> View,O=Symantec Corp.,CN=psslnoov.symantec.com
> 
> https://crt.sh/?id=11876802 would be an example then.

On further investigation, this certificate is revoked, at 4 Jan 2016 17:42 UTC
according to the CRL (and the OCSP server also responds accordingly). (Its
notBefore datetime is 4 Jan 2016 00:00 UTC.)

> 
> The Class 3 Internal Server CA - G3 appears to have a cert issued from 
> "VeriSign
> Class 3 Public Primary Certification Authority - G5", which is an included CA
> with the websites trust bit enabled.
> 
> 
>> I didn't have time to file bugs for this yet.
>>
>>
>> Kurt
>>
> 

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

Re: SHA1 certs issued this year chaining to included roots

[Charles Reiss]

On 01/19/16 03:23, Kurt Roeckx wrote:
> On Tue, Jan 19, 2016 at 01:49:21AM +0000, Charles Reiss wrote:
>> Via censys.io, I found a couple SHA-1 certs with notBefore dates from this 
>> year
>> which chain to root CAs in Mozilla's program:
> 
> I also have some from C=US,O=VeriSign\, Inc.,OU=VeriSign Trust
> Network,OU=Terms of use at https://www.verisign.com/rpa
> (c)10,CN=VeriSign Class 3 International Server CA - G3".  I'm not
> sure that CA is still included, but I think it it.
> 
> It includes certificates like C=US,ST=California,L=Mountain
> View,O=Symantec Corp.,CN=psslnoov.symantec.com

https://crt.sh/?id=11876802 would be an example then.

The Class 3 Internal Server CA - G3 appears to have a cert issued from "VeriSign
Class 3 Public Primary Certification Authority - G5", which is an included CA
with the websites trust bit enabled.


> I didn't have time to file bugs for this yet.
> 
> 
> Kurt
> 

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

Re: Policy Update Proposal: Timeline for Disclosing SubCAs

[Charles Reiss]

On 12/15/15 01:48, Peter Bowen wrote:
> On Mon, Dec 14, 2015 at 5:39 PM, Kathleen Wilson  wrote:
>>
>> Another thing to consider in updating the policy is in regards to test
>> certificates versus certificates issued to customers.
>> e.g. Does the disclosure need to happen before test certificates are issued?
>> Or does the disclosure just need to happen before non-test certificates are
>> issued? (or certificates are issued to customers, or such)
> 
> Kathleen,
> 
> There is no definition of "test certificate" so carving out a specific
> exception for test certificates seems unworkable.  That being said, it
> would seem reasonable that one should be able to generate a keypair
> for a new CA, cut a cross-certificate from an existing CA, and issue
> the first certificate(s) in one ceremony.  I don't think it is
> reasonable to require a waiting period between key generation and
> certificate issuance.
> 
> Therefore, I would revise my earlier recommendation, and suggest
> placing a timeliness requirement on disclosure -- publicly disclose
> within X days of first issuance.  If there is a strong interest in
> pre-disclosure, then maybe allowing disclosure of the planned
> Distinguished Name of the CA and applicable documents would be
> appropriate with a supplementary disclosure of the public key after
> generation.

I think, at least for externally operated subCAs, Mozilla should require
predisclosure. This would make it clear that the parent CA was committed to
disclosing the subCA. I'm sceptical of an 'X days after issuing' requirement to
provide similar assurance given that externally one can't generally distinguish
between a parent CA complicity issuing a series of short-lived subCAs until
something goes wrong and a parent CA being fooled into issuing a subCA that gets
abused very quickly.

Also, whatever timeline Mozilla provides for disclosure needs to avoid the
catch-22 when issuing a cross-certificate for an existing CA, for which first
issuance is many days before the subCA certificate is issued.

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

Re: ComSign Root Renewal Request

[Charles Reiss]

On 12/14/15 17:56, Eli Spitzer wrote:
> The SubCA "Comsign Ev SSL CA" is at its initial development stages. It was
> indeed created under "Comsign Global Root CA", but so far we only issued a
> handful of test certificates from it. We have no plans to issue public
> certificates from it at the moment, since the EV trust bit will not be active
> any time soon.

Mozilla's policy requires subCAs to be publicly disclosed "before any []
subordinate CA is allowed to issue certificates." How was this performed for
this subCA?

> 
> censys.io probably picked up the certificate from a test website that is used
> only for development purposes.
> 
> Comsign is not requesting the EV trust bit at the moment, but we are planning
> to so sometime in the near future. Probably not before the end of 2016.
> 
> Eli Spitzer | Information security & System Management | Comda
> 

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

Re: ComSign Root Renewal Request

[Charles Reiss]

On 12/10/15 20:01, Kathleen Wilson wrote:
> This request is to include the "ComSign Global Root CA" root certificate, and
> enable the Websites and Email trust bits. This root will eventually replace 
> the
> "ComSign CA" root certificate that is currently included in NSS, and was
> approved in bug #420705.
> 
> ComSign is owned by Comda, Ltd., and was appointed by the Justice Ministry as 
> a
> CA in Israel in accordance with the Electronic Signature Law 5761-2001. 
> ComSign
> has issued electronic signatures to thousands of business people in Israel.
[snip]

> * CA Hierarchy: This root has internally-operated subordinate CAs: ComSign ISA
> Global CA, ComSign Corporation CA, ComSign Professionals CA, and ComSign
> Organizational CA.
> CA Hierarchy Diagram: https://bugzilla.mozilla.org/attachment.cgi?id=8608692

Via Censys.io, I noticed a subCA with CN "Comsign EV SSL CA" whose subCA cert is
reproduced below.

-BEGIN CERTIFICATE-
MIIG1zCCBL+gAwIBAgIQcybbitmPn4IXQtwZX2fD8DANBgkqhkiG9w0BAQsFADBF
MR8wHQYDVQQDExZDb21TaWduIEdsb2JhbCBSb290IENBMRUwEwYDVQQKEwxDb21T
aWduIEx0ZC4xCzAJBgNVBAYTAklMMB4XDTE1MDkyNDExMTgyM1oXDTI1MTAyMjE5
MDAwMFowUzELMAkGA1UEBhMCSUwxETAPBgNVBAcTCFRlbCBBdml2MRUwEwYDVQQK
EwxDb21zaWduIEx0ZC4xGjAYBgNVBAMTEUNvbXNpZ24gRVYgU1NMIENBMIICIjAN
BgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA9802wpU9bUwRopTfxwDsjugmljHX
MVMt4stqAZuCZO2EbHAvFVdT9vGnzQ2AxbHEpTPTlJZdBpYsUKZPZW56MEs17a9R
SYIDJWRs2GrmQIFoSxqIkjkHCpfzzAA6UM4PvqTYuCkvmaUEV3GtK3RvVfSqYlCQ
Kszcj+BLq5q9lvfQh4ygN8Cgj+O7s8svh+D08ho7LHyf23Ng+lrYea+zlJosn+9C
f97DpkK+Ceg1wgjmFPWE6vKil1euayyf69NLlufkbd99Dej0JUX0hPkewNEbPXc9
wANWQBC/HAu/QR4cLmMIU+MbSFPVBZmUIyZKQnEe4AVcnpk4rL7HV7xOb/Q1JGOE
wkyoXWMHh+qaxzmYxA27360LTvQ+ik6cOruCZhFIT/3G9bF9vx0D0wn7MTJuiaoI
MMjT8ayBGsqB3U31omLHo2AXLwpBC1thj4aYSMFio/vIRfglslny/cQM6RXt1Xk6
qC/b1JUK1boUnjFgxjClG/dmSdjJrK0T/zr11oKaxEkdZ2FjHXwBgsF2/MVGCqvK
Kv6hAgmptEl4kvrgk+O5RGDfceNE28OpJJ89Ew/UnAHhaRqVzo1yT6MHD2Pw5Rnx
sau7cVblH7iGu+GXOLBH6QjjrQs5Ul9jXQQ0waFQOE2B0i2lZicP9t05bh+445dH
EUU8BojywPEbNn8CAwEAAaOCAbMwggGvMIGCBggrBgEFBQcBAQR2MHQwKwYIKwYB
BQUHMAGGH2h0dHA6Ly9vY3NwMS5jb21zaWduLmNvLmlsL29jc3AwRQYIKwYBBQUH
MAKGOWh0dHA6Ly9mZWRpci5jb21zaWduLmNvLmlsL2NhY2VydC9Db21TaWduR2xv
YmFsUm9vdENBLmNydDAfBgNVHSMEGDAWgBQCRZPYDUhirGm6rgZbPvuqJpFQsTAS
BgNVHRMBAf8ECDAGAQH/AgEAMD0GA1UdIAQ2MDQwMgYEVR0gADAqMCgGCCsGAQUF
BwIBFhxodHRwOi8vd3d3LmNvbXNpZ24uY28uaWwvQ1BTMIGEBgNVHR8EfTB7MDyg
OqA4hjZodHRwOi8vZmVkaXIuY29tc2lnbi5jby5pbC9jcmwvQ29tU2lnbkdsb2Jh
bFJvb3RDQS5jcmwwO6A5oDeGNWh0dHA6Ly9jcmwxLmNvbXNpZ24uY28uaWwvY3Js
L0NvbVNpZ25HbG9iYWxSb290Q0EuY3JsMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4E
FgQU7fGGKZqDjBRnn7pjoL3PRHlkAdIwDQYJKoZIhvcNAQELBQADggIBAHxBbq2k
jzKZVcI6kL++GGAfojlBv/x2ci6q0c7LOois6Mu+QiD3QhplSuZtAY5GZ7rLdN28
3cI4ufh+roNGmZDuh6E4ZMQG1Kd+DbfpCsEKo8tq5nmXCjdp2f4+eK2LAuXb0Z38
fsodqjnsGfMJuVg1F4ofRzX/WnfY2vgVV5Fo7ng5hwdVzIsywxgTd4JBCrfZJsRE
Ci+mxfIu5kEZiSftciaoFjqWkI+HUYE3H+Fsmq0K59sMg5oYZpwo/LFBKfRIBunC
IBKNCODFTVIwXjtrY3xkAYPac6XmTDTNqwu7sLscZ9K4psBJokhe4HVFrVarXpXi
khFSTlkD4ZTgJSnikmmgBzlPieMUqeGfu7vWymVIhU+2bbS/orDrX8Sm5QIMw3xz
WMuPmGwB3FVzBc9TdqjNdw1+iHgCIEpvuBiLIMsIAkRQzaxifYcrTv6zFx5xRKuQ
MWKLgyGeTG+WZscOtP7eWxwvzhGMmAAahUqSgCvp01lk5rtOzYF4kYM4fvQRnkJB
MmgZ0gEbUtjxPI8JiOc9sI6I73M8IC7LqrqI3NXQoVyri0smRD5elgIHfksBrOS1
Yl6zC5ekM0GDkatfX7l29OteGtVHVaUj4Ti+esT/D8CuBL9bHqIMjrJePzuE29+Z
GgiV55sP/5iWAHIhoqvHBmswvEEHBozrAh6I
-END CERTIFICATE-


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

Re: Policy Update Proposal: Timeline for Disclosing SubCAs

[Charles Reiss]

On 11/19/15 23:09, Kathleen Wilson wrote:
> By the time version 2.3 of Mozilla’s CA Cert Policy is published, I hope to 
> have
> issued a CA Community License to every included CA. Taking that into
> consideration; I propose changing the policy as follows.
> 
[snip]
> 
> As always, I will appreciate your thoughtful and constructive input about this
> proposal.

Shouldn't there also be something in the policy about when and how CAs should
provide updated annual public attestation statements for the subCAs? (I assume
the 30 days from the updated audit being available to the CA in the Maintainence
Policy is appropriate for this.)

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

Re: Policy Update Proposal: Timeline for Disclosing SubCAs

[Charles Reiss]

On 11/04/15 00:24, Kathleen Wilson wrote:
> Topic to discuss [1]:
> “(D3) Make the timeline clear about when the audit statements and disclosure 
> has
> to happen for new audited/disclosed subCAs.
> 
> Section 10 of the Inclusion Policy says:
> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> 
> “The CA with a certificate included in Mozilla’s CA Certificate Program MUST
> disclose this information before any such subordinate CA is allowed to issue
> certificates.”
> 
> Additionally, section 8.1 of version 1.3 of the Baseline Requirements 
> specifies
> when the audits must occur: “before issuing Publicly-Trusted Certificates, the
> CA SHALL successfully complete a point-in-time readiness assessment performed 
> in
> accordance with applicable standards under one of the audit schemes listed in
> Section 8.1. 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.”
> 
> What further clarification needs to be added to Mozilla’s CA Certificate 
> Policy
> to make it more clear when the audit statements and disclosure has to happen 
> for
> new subCAs?

My impression is that Mozilla need not be explicitly notified of new subCAs; the
disclosure may take the form of an update on the CA's website (perhaps even just
a new version of the CPS). If so, this would seem to make it difficult for
Mozilla or others to monitor adherence to this policy.

For a small number of CAs, I'm not sure where I am supposed to find these
disclosures. For example, where are the (non-DigiCert/Verizon-operated) subCAs
of Baltimore CyberTrust Root disclosed? (I checked the CPS, CP,
http://cybertrust.omniroot.com/repository/ ,
https://www.digicert.com/digicert-root-certificates.htm , searched
bugzilla.mozilla.org, and didn't find it -- I assume I'm missed something?)

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

Re: Symantec Test Cert Misissuance Incident

[Charles Reiss]

On 10/28/15 21:30, Kathleen Wilson wrote:
> On 10/28/15 2:14 PM, Kathleen Wilson wrote:
>> Google has blogged about this:
>>
>> https://googleonlinesecurity.blogspot.com/2015/10/sustaining-digital-certificate-security.html
>>
>>
> 
> All,
> 
> We should discuss what actions Mozilla should require of Symantec, and what
> would be the penalty of not completing those actions.
> 
> Of course, we still do not have the final report from Symantec, which may 
> change
> things.
> 
> According to the article, here is what Google is requiring of Symantec:
> 
> 1) as of June 1st, 2016, all certificates issued by Symantec itself will be
> required to support Certificate Transparency
> 
> 2) further update their public incident report with: A post-mortem analysis 
> that
> details why they did not detect the additional certificates that we found.
> Details of each of the failures to uphold the relevant Baseline Requirements 
> and
> EV Guidelines and what they believe the individual root cause was for each 
> failure.

Based on the tone of Symantec's blog post, I fear such an assessment will have
root causes like "employees failed to follow written domain validation
procedures". Such a result would be unfortunate, because it would provide little
insight into how the BRs and Mozilla's policies can be changed to prevent
misissuance in the future.

If the root cause is going to be "human error" of that sort, Mozilla should try
to obtain an understanding of Symantec's procedures that should have prevented
it (training, policy compliance monitoring, automation/UX provided by
certificate issuance tools, availability of test CAs, etc.).

[snip]
> Do you all think we should simply require the same action items?
> 
> Is there need to duplicate all of these requirements?
> 
> Is there anything else we should require?

On an different issue, I am curious whether any of the misissued certificates
were reviewed as part of the quarterly self-audit of a 3% random sample of
certificates required by the BRs.

> 
> As always, I will appreciate your thoughtful and constructive input into this
> discussion.
> 
> Kathleen
> 

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

Re: FNMT Root Inclusion Request

[Charles Reiss]

On 10/26/15 15:57, rafa...@gmail.com wrote:
> El miércoles, 21 de octubre de 2015, 22:43:15 (UTC+2), Charles Reiss
> escribió:
>> On 10/21/15 19:17, Kathleen Wilson wrote:
>> 
>> 
>> What are the apparent subCAs with CNs 'AC FNMT Usuarios' 
>> [https://crt.sh/?caid=6664 ] and 'ISA CA' [https://crt.sh/?caid=947
>> (example EE cert: https://crt.sh/?id=8983568 )]?
> 
> "AC FNMT Usuarios" is the subCA that issues qualified certificates
> exclussively for natural persons (Spanish citizens). This subCA started
> operations on february 2015.
> 
> Regarding "ISA CA", the European Commission awarded the FNMT-RCM Company a
> contract for PKI services within the scope of European Public Administration
> (ISA Program). This subCA issues certificates exclusively within that scope
> and only for the specified EU Institutions entitled by the European
> Commission to request ISA SSL certificates.
> 
> All of the active server certificates have been issued for domains under: -
> testa.eu for STESTA net. (STESTA is the European Community's own private
> network, composed of the EuroDomain backbone and Local Domain networks.The
> EuroDomain is totally isolated from the public Internet. This guarantees
> restricted access as only administrations may access the EuroDomain. Security
> is also enhanced by the implementation of IPSEC technology to prevent
> eavesdropping and advanced encryption mechanisms.) - europa.eu which holds
> internal services of EU public administrations.
> 
> Both, europa.eu and testa.eu are domains property of the European Comission
> itself as you can verify at http://www.eurid.eu.
> 
> The server certificate that you refer (https://crt.sh/?id=8983568) is the
> only exception. "ec.fnmt.es" is a domain property of FNMT-RCM that just holds
> the portal for accesing ISA CA products and services.
> 
> The reasons why this subCAs don't figure in request are: 
> - "AC FNMT Usuarios" doesn't issue server certificates

Since its subCA certificate is technically capable of having server
certificates chaining through it (there's no extendedKeyUsage extension that
would prevent this), under section 8 of Mozilla's certificate policy and section
8.1 of the BRs, it must be publicly disclosed and audited.

> - ISA CA server certificates are issued exlusively to a very restricted
> (almost private) environment

Again, based on its subCA certificate, the ISA CA is clearly required to be
publicly disclosed and audited under Mozilla's policy and the BRs.

My concern is not that it has been used to misissue certificates in the past,
but that lax domain/IP control validation procedures may allow mistakes in the
future.

It is fine to operate restricted subCAs like this (many commercial CAs seem to
do it for large organizations), but since they are capable of producing publicly
trusted certificates, they must follow the same standards as if they were
issuing certificates for the general public.

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

Re: FNMT Root Inclusion Request

[Charles Reiss]

On 10/23/15 08:10, almo...@gmail.com wrote:
> El miércoles, 21 de octubre de 2015, 22:43:15 (UTC+2), Charles Reiss  
> escribió:
>> On 10/21/15 19:17, Kathleen Wilson wrote:
>>> FNMT has applied to include the "AC RAIZ FNMT-RCM" root certificate and 
>>> enable
>>> the Websites trust bit.
>>
>> [snip]
>>
>>> * CA Hierarchy
>>>
>>> ** This root has internally-operated subordinate CAs
>>
>>> - "AC Componentes Informáticos" issues certificates for SSL Servers and code
>>> signing.
>>> - "AC Administración Pública" is an updated version of the "APE CA" in 
>>> order to
>>> meet new requirements from Spanish Government about certificates of Public
>>> Administrations.
>>> - "APE CA" is no longer used.
>>
>>
>> What are the apparent subCAs with CNs 'AC FNMT Usuarios'
>> [https://crt.sh/?caid=6664 ] and 'ISA CA' [https://crt.sh/?caid=947 (example 
>> EE
>> cert: https://crt.sh/?id=8983568 )]?
> 
> 'AC FNMT Usuarios' are for individuals.
> 
> 'ISA CA' are for staff working for the European Commission or any institution 
> or Agency of the European Union.
> 

I notice that the audit report Kathleen linked to explicitly mentions the other
CAs ("the Delegated Certification Authorities; 'CA Administración Pública' y 'CA
Componentes Informáticos'" [sic]) but not these CAs. Is there a reason for that?

https://www.sede.fnmt.gob.es/documents/11614/67070/dpcec_english.pdf appears to
be translated CPS for the ISA CA sub-CA. For server certificates, this document
says:

12.2.2.1.3.381:
FNMT – RCM shall check, through the information systems that the Local
Registration Authority Officer (LRA Officer) authorised for each case have
available to them, that the domain name or IP address to include in the Web
Server Certificate is owned by the applicant Organization or Competent Body. In
the event that that such a check is not possible, __the FNMT-RCM shall accept
the Organization or Competent Body’s ownership over said names or addresses on
the basis of the corresponding application__.

[emphasis added]

I don't think that last option ("accept [...] on the basis of the corresponding
application") is acceptable for verifying domain name or IP address ownership
under the BRs.

(It's also not clear to me what the other option ("check, through the
information systems [...], that the domain name or IP address [..] is owned")
actually entails. I'd hope it means checking the registrar's databases...)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

[Charles Reiss]

On 03/23/15 22:47, Richard Barnes wrote:
 Dear dev.security.policy,
 
 It has been discovered that an intermediate CA under the CNNIC root has
 mis-issued certificates for some Google domains.  Full details can be found
 in blog posts by Google [0] and Mozilla [1].  We would like to discuss what
 further action might be necessary in order to maintain the integrity of the
 Mozilla root program, and the safety of its users.
 
 There have been incidents of this character before.  When ANSSI issued an
 intermediate that was used for MitM, name constraints were added to limit
 its scope to French government domains.  When TurkTrust mis-issued
 intermediate certificates, they changed their procedures and then they were
 required to be re-audited in order to confirm their adherence to those
 procedures.
 
 We propose to add name constraints to the CNNIC root in NSS to minimize the
 impact of any future mis-issuance incidents.  The “update procedures and
 re-audit” approach taken with TurkTrust is not suitable for this scenario.
 Because the mis-issuance was done by a customer of CNNIC, it’s not clear
 that updates to CNNIC’s procedures would address the risks that led to this
 mis-issuance.  We will follow up this post soon with a specific list of

Can Mozilla consider more serious measures like also distrusting all CNNIC
certificates after a given date?

In light of CNNIC's apparent lack of monitoring or auditing of this subCA, CNNIC
should have anticipated that certs issued by this subCA would be substantially
noncompliant with the BRs and Mozilla's policy -- especially since they require
much more than domain validation. In addition, the subCA itself seems an
unambiguous violation of Mozilla's inclusion policy (MUST disclose this
information before any such subordinate CA is allowed to issue certificates).
Mozilla should make clear that such recklessness will ultimately result in CAs
being removed from Mozilla's root program.


 proposed constraints.
 
 Please send comments to this mailing list.  We would like to have a final
 plan by around 1 April.
 
 Thanks,
 --Richard
 
 [0]
 http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html
 [1]
 https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnnic-intermediate-certificate/
 

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

Re: Consequences of mis-issuance under CNNIC

[Charles Reiss]

On 03/23/15 22:47, Richard Barnes wrote:
 Dear dev.security.policy,
 
 It has been discovered that an intermediate CA under the CNNIC root has
 mis-issued certificates for some Google domains.  Full details can be found
 in blog posts by Google [0] and Mozilla [1].  We would like to discuss what
 further action might be necessary in order to maintain the integrity of the
 Mozilla root program, and the safety of its users.
 
 There have been incidents of this character before.  When ANSSI issued an
 intermediate that was used for MitM, name constraints were added to limit
 its scope to French government domains.  When TurkTrust mis-issued
 intermediate certificates, they changed their procedures and then they were
 required to be re-audited in order to confirm their adherence to those
 procedures.
 
 We propose to add name constraints to the CNNIC root in NSS to minimize the
 impact of any future mis-issuance incidents.  The “update procedures and
 re-audit” approach taken with TurkTrust is not suitable for this scenario.
 Because the mis-issuance was done by a customer of CNNIC, it’s not clear
 that updates to CNNIC’s procedures would address the risks that led to this
 mis-issuance.  We will follow up this post soon with a specific list of
 proposed constraints.
 
 Please send comments to this mailing list.  We would like to have a final
 plan by around 1 April.

Does any part of CNNIC's CPS cover issuing external subCAs at all? When did
CNNIC start issuing external subCAs?

Did CNNIC take steps suggesting they planned to comply with Mozilla's subCA
policy for this CA:
- Did they have a CPS for this subCA?
- Is there evidence that any auditing of this subCA took place/was planned?



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