Re: ComSign Root Renewal Request

[Kathleen Wilson]

On 12/14/15 1:17 PM, Charles Reiss wrote:

On 12/14/15 19:56, Eli Spitzer wrote:

On Monday, December 14, 2015 at 8:59:03 PM UTC+2, Charles Reiss wrote:

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?



The request to add "Comsign Global Root CA" was submitted to Mozilla on
2014-11-30. The Comsign CA Hierarchy details was submitted to Mozilla on
2015-05-21 On both dates there was no SubCA called "Comsign EV SSL CA" in
existence. It was created on 2015-09-24, as can be seen in the certificate
that you have found. Since this Root CA request is taking very long time to
progress, naturally some processes and taking place in Comsign over time, and
we are committed to disclose any development to Mozilla. However, this SubCA
has never issued any certificate to end-entities other than Comsign itself.
Moreover, this SubCA may even be revoked soon before it will ever do so,
since for now it is strictly for testing purposes. It is possible to say that
it was a simple oversight, but in fact this SubCA does not ever fall under
the requirement of the policy that it will not be "allowed to issue
certificates" - since Comsign is not even considering to issue any
certificate from it before we have the EV trust bit.


The existence of test certificates which chain to this subordinate CA
certificate (like the one censys.io found) clearly puts it in the scope of
Mozilla's disclosure policy.

Mozilla's policy says "issue certificates", not "issue non-test certificates" or
"issue certificates to third-parties".




This is a good example of why Mozilla's policy needs to be updated to be 
more clear about this.


See the discussion called "Policy Update Proposal: Timeline for 
Disclosing SubCAs"

https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/EDRp1Fil3u8/ub33LOoDAgAJ

The CA Community in Salesforce will make it easier to disclose such 
information too.


Thank you for raising this point. I will update my records with this 
information, but I do not see it as a show-stopper for this request at 
this time.


Kathleen


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

Re: Remove trust of Symantec's Class 3 Public Primary Certification Authority?

[Andrew Ayer]

On Sat, 12 Dec 2015 16:56:04 -0800
Yuhong Bao  wrote:

> I think this and most of the other 1024-bit roots was removed or
> restricted to email in Mozilla some time ago (last remaining one is
> Equifax). They had been consider obsolete for a long time.

Indeed, the Verisign Class 3 Public Primary Certification Authority is
currently email-only.  I'm curious if there's any reason the email
trust bit should not be removed as well, considering that Symantec's
announcement[1] only lists TLS and code signing as the uses of this
root.

Thanks,
Andrew

[1] 
https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content=ALERT1941=LIST=en_US
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Eli Spitzer]

On Monday, December 14, 2015 at 8:59:03 PM UTC+2, Charles Reiss wrote:
> 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?
> 

The request to add "Comsign Global Root CA" was submitted to Mozilla on 
2014-11-30.
The Comsign CA Hierarchy details was submitted to Mozilla on 2015-05-21
On both dates there was no SubCA called "Comsign EV SSL CA" in existence. It 
was created on 2015-09-24, as can be seen in the certificate that you have 
found.
Since this Root CA request is taking very long time to progress, naturally some 
processes and taking place in Comsign over time, and we are committed to 
disclose any development to Mozilla. However, this SubCA has never issued any 
certificate to end-entities other than Comsign itself. Moreover, this SubCA may 
even be revoked soon before it will ever do so, since for now it is strictly 
for testing purposes.
It is possible to say that it was a simple oversight, but in fact this SubCA 
does not ever fall under the requirement of the policy that it will not be 
"allowed to issue certificates" - since Comsign is not even considering to 
issue any certificate from it before we have the EV trust bit.


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

Re: HARICA Root Renewal Request

[Dimitris Zacharopoulos]

On 11/12/2015 12:55 μμ, Dimitris Zacharopoulos wrote:

On 11/12/2015 1:29 πμ, Kathleen Wilson wrote:

This request is to include the “Hellenic Academic and Research
Institutions RootCA 2015” and “Hellenic Academic and Research
Institutions ECC RootCA 2015” root certificates, and enable the 
Websites and Email trust bits for both roots.


Hellenic Academic and Research Institutions Certification Authority 
(HARICA) is a non-profit organization serving the Greek Academic and 
Research Community; operated by the Greek Universities Network 
(www.gunet.gr).


The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1201423

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=8697399

Noteworthy points:

* The primary documents are the CPS; provided in Greek and English

Document Repository: http://www.harica.gr/procedures
CPS: http://www.harica.gr/documents/CPS-EN.pdf

* CA Hierarchy:
** The new roots will be cross-signed by “Hellenic Academic and 
Research Institutions RootCA 2011” to assist the rollover.
 ** “Hellenic Academic and Research Institutions RootCA 2011” 
currently has 20 internally operated and technically-constrained subCAs.

There is currently one externally-operated subordinate CA:
- Aristotle University of Thessaloniki
- http://www.auth.gr, http://it.auth.gr
- http://www.pki.auth.gr/certs/AuthCentralCAR3.pem, (to be 
decommissioned by Sep 2015)

- http://www.pki.auth.gr/certs/AuthCentralCAR4.pem
- http://www.pki.auth.gr/certs/AuthCentralCAR5.pem
- AuthCentralCAR4 and AuthCentralCAR5 issue sub-CAs and end 
user/server certificates

- http://www.pki.auth.gr/documents/CPS-EN.pdf
- Sections in CP/CPS demonstrating the measures to verify:
-- Ownership of domain name: 3.2.2, 3.2.3.2 and 3.2.5
-- Ownership of e-mail: 3.2.2, 3.2.3.1 and 3.2.5
- For all certificates chaining up to these Sub-CA, both the 
organization and the ownership/control of the domain are verified.
- This CA is currently operated by the same administration team as 
the HARICA Root CA.

- OCSP: http://ocsp.pki.auth.gr
- Audit: http://pki.auth.gr/documents/AUTH-ETSI_CERTIFICATE_AUTH_W_ANNEX

** “Hellenic Academic and Research Institutions ECC RootCA 2015” 
currently has the following internally-operated subCAs:

- Hellenic Academic and Research Institutions ECC AdminCA R1
We plan to issue the following internally operated subCAs for 
specific usages:

- ECC Client Authentication and SecureEmail
- ECC Code Signing
- ECC SSL (DV/OV) Server Certificates
There are currently no externally operated subCAs issued from this 
root. According to our CP/CPS, in case of externally operated CAs, 
they will either be technically constrained or publicly disclosed and 
audited.


* This request is to enable the Websites and Email trust bits for 
both root certs. HARICA is not requesting EV treatment.


** CPS section 3.2.3.1: HARICA central RA uses three methods for 
e-mail ownership and control verification:
- The first method uses simple e-mail verification. The user enters 
the e-mail address at the initial certificate request form and a 
verification e-mail is sent to the user with a link to a unique web 
page. After following this link, an e-mail is sent to the 
institution's network operation center mail administrator that 
requires an approval based on the full name entered by the user and 
the user's email. This approval requires the identification of the 
user with his/her physical presence and an acceptable official document.
- The second method uses an LDAP server. The user enters the personal 
e-mail address at the initial certificate request form and the 
corresponding password. This information is verified against the 
institution's LDAP server. If the verification is successful, the RA 
queries the real name of the user and creates the certificate 
request. In order for a user to be listed in the Institutional 
Directory server, the institution must have verified the user with 
his/her physical presence and an acceptable official photo-id document.
- The third method uses a Single Sign On (SSO) architecture based on 
the SAML specification. The user enters the personal e-mail address 
at the initial request form and is then redirected to the appropriate 
web page of the Identity Provider. The Identity Provider verifies the 
user and returns the real name and the email address of the user as 
attributes to the Registration Authority. In order for a user to be 
verified by the Identity Provider of an institution, the institution 
must have verified the user with his/her physical presence and an 
acceptable official photo-id document.


** CPS section 3.2.3.2: For each Fully-Qualified Domain Name listed 
in a Certificate, the CA SHALL confirm that, as of the date the 
Certifiate was issued, the Applicant either is the Domain Name 
Registrant or has control over the FQDN by:
- 

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

[Eli Spitzer]

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.

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