Actalis Root Inclusion Request

[Kathleen Wilson]

Actalis has applied to add the “Actalis Authentication CA G1” root
certificate, and turn on the Websites and Code Signing trust bits.

Actalis is a public CA offering PKI services to a wide number of
customers, mainly banks and local government. Actalis is a Qualified
certification service provider according to the EU Signature Directive
(Directive 1999/93/EC). Actalis designs, develops, delivers and manages
services and solutions for online security, digital signatures and
document certification; develops and offers PKI-enabling components,
supplies complete digital signature and strong authentication kits
(including hardware and software), delivers ICT security consultancy and
training.

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

And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Actalis

Information Gathering Document:
https://bugzilla.mozilla.org/attachment.cgi?id=533004

Noteworthy points:

* Cert Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=405122

* The CPS is provided in Italian and English.

CPS for SSL and Code Signing Certs (English):
http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLServer_CodeSigning_v2.0.3_EN
(PDF document)

* This “Actalis Authentication CA G1” root certificate directly signs
end-entity certificates for SSL and Code Signing. Technical security
controls are described in section 6 of the CPS, and Actalis has a
detailed Security Plan in place that is reviewed by their national
supervising authority (CNIPA).

* The request is to enable the Websites and Code Signing trust bits.

** CPS section 3.2.1: The proof-of-possession, by the applicant, of the
private key corresponding to the requested certificate is based on the
cryptographic verification of the CSR (Certificate Signing Request) sent
to the CA. In fact the applicant must send its own public key to the CA
in the form of a CSR in PKCS#10 format [RFC2314]. The CA shall verify
that the digital signature in the CSR is valid.
Transmission of the CSR to the CA is normally done over the web
(https://portal.actalis.it) or via electronic mail.

** CPS section 3.2.2: Authentication of the identity of the applicant
organisation includes in any case a lookup in the relevant CCIAA
(Chamber of Commerce, Industry, Crafts and Agriculture) database. The
name of the organisation declared by the client must correspond with the
company name as registered in the chamber of commerce. In case of
mismatch, the certificate application shall be rejected.

** CPS section 3.2.3: The individual identities indicated in the
certificate application are verified over the phone, by contacting the
person declared as “requestor” in the certificate application form.
The CA reserves the right to perform further verifications in order to
validate individual identities.

** CPS section 3.3: In the case of SSL Server certificates, the CA shall
also lookup the WHOIS record to verify that the owner organisation of
the domain is the same as the applicant. In the case when the details do
not match the application shall be rejected. Nonetheless, it is possible
that the owner organisation has delegated the management of its domain
to the party applying for the certificate. In this case, the application
shall be accepted if a proof of such delegation is provided to the CA
(i.e. copy of registration application for the domain sent to the
manager by the owner organisation of the domain).
In the case of Code Signing certificates, it is not allowed that the
certificate be requested by an organisation different than the one to
which the certificate is to be attributed: client and subscriber must
coincide.
The CA reserves the right to perform any further verification as required.

** CPS section 3.4: The CA does not verify the electronic mail address
indicated in the application form.
In general, the CA does not verify the correctness of any information
received from the applicant which is not intended to be used in
security-sensitive fields of the certificate and which is not necessary
for the issue and subsequent management (suspension, re-activation,
revocation) of the certificate.

* EV Policy OID: Not EV

* Test Website: https://portal-pte.actalis.it/

* CRL: http://portal.actalis.it/Repository/AuthCA1/getCRL
** (Next Update: 30 hours)

* OCSP: http://ocsp.actalis.it/AUTH-G1

* Audit: Audits are performed by Centro Nazionale per L’Informatica
nella Pubblica Amministrazione (CNIPA) according to CNIPA Government
Guidelines which are structured in accordance with the schedule of the
technical specifications ETSI TS 101 456. Audits are performed every 18
months. An audit statement was attached to the bug:
https://bugzilla.mozilla.org/attachment.cgi?id=519599 (2009.11.24)
Actalis is also listed as an accredited national certification service
provider on the CNIPA website:
http://www.digitpa.gov.it/certificatori_firma_digitale
The CNIPA criteria is the link called “Linee guida per la vigilanza sui
certificatori qualificati” on this page:
http://www.digitpa.gov.it/firma-digitale/certificatori-accreditati
http://www.digitpa.gov.it/sites/default/files/linee%20guida%20per%20la%20vigilanza%20sui%20certificatori%20qualificati%20v1.2.pdf
Section 1.3: These Guidelines are structured in accordance with the
schedule of the technical specifications ETSI TS 101 456 and ETSI
Technical Report TR 102 437.

Potentially Problematic Practices
(http://wiki.mozilla.org/CA:Problematic_Practices):

* Issuing end entity certificates directly from roots
** CPS section 6 describes the CA’s technical security controls.
** From Actalis: Apart from the information already provided in the CPS,
we have a detailed Security Plan in place that can only be disclosed to
our national supervising authority (CNIPA).

* Delegation of Domain / Email validation to third parties
** CPS Section 1.3.2: The RA activities are normally performed by
Actalis, but in certain circumstances these can be delegated to other
parties based on a specific delegation agreement.
** CPS Secton 4.2: the RA shall perform the following:
- insert the applicant data in the registration database;
- verify that the identification data contained in the CSR are coherent
with that supplied in the application form;
- verify the identity of the applicant and possession of the private key
corresponding to the CSR, as described in section 3.2;
- perform the additional verifications described in section 3.3.
** CPS Section 8.4: Audits on external RAs aim at verifying the respect,
by each audited RA, of the delegation agreement (see section 1.3.2).
** CPS section 8.5: in the event that an RA is found not to comply with
the delegation agreement, a period of time is agreed between Actalis and
the RA wherein the non-compliances must be resolved. Should the RA fail
to resolve the problems within the established deadline, Actalis revokes
the RA credentials that are necessary to gain access to Actalis’ on-line
registration services. Further actions are then negotiated between
Actalis and the offending RA. In the event that Actalis has suffered any
damage as a consequence of the RA’s misconduct, section 9.8 applies.
** CPS section 9.8: RAs shall pay compensation of any damages suffered
by Actalis as a consequence of their non respecting the delegation
agreement and this CPS

This begins the discussion of the request from Actalis to add the
“Actalis Authentication CA G1” root certificate, and turn on the
Websites and Code Signing trust bits. At the conclusion of this
discussion, I will provide a summary of issues noted and action items.
If there are no outstanding issues, then this request can be approved.
If there are outstanding issues or action items, then an additional
discussion may be needed as follow-up.

Kathleen

[Luciano Castro - Actalis]

On 17 Mag, 19:30, Kathleen Wilson <kathleen95...@yahoo.com> wrote:
> Actalis has applied to add the “Actalis Authentication CA G1” root
> certificate, and turn on the Websites and Code Signing trust bits.

[..]
> Kathleen

Hi All,

We are available to any comment / request / suggestion / observation.

Luciano Castro

[Kathleen Wilson]

On 5/17/11 10:30 AM, Kathleen Wilson wrote:
> Actalis has applied to add the “Actalis Authentication CA G1” root
> certificate, and turn on the Websites and Code Signing trust bits.
>
> Actalis is a public CA offering PKI services to a wide number of
> customers, mainly banks and local government. Actalis is a Qualified
> certification service provider according to the EU Signature Directive
> (Directive 1999/93/EC). Actalis designs, develops, delivers and manages
> services and solutions for online security, digital signatures and
> document certification; develops and offers PKI-enabling components,
> supplies complete digital signature and strong authentication kits
> (including hardware and software), delivers ICT security consultancy and
> training.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=520557
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Actalis
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=533004
>
> Noteworthy points:
>
> * Cert Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=405122
>
> * The CPS is provided in Italian and English.
>
> CPS for SSL and Code Signing Certs (English):
> http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLServer_CodeSigning_v2.0.3_EN

Would at least two people please review and comment on this request from

Actalis to add the “Actalis Authentication CA G1” root certificate, and

turn on the Websites and Code Signing trust bits?

Kathleen

[Jose Manuel Torres]

HI,

I've been reading SSLServer CPS (
http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLServer_CodeSigning_v2.0.3_EN
)
and I would like to get more info regarding with the established procedure
for IDENTIFICATION AND AUTHENTICATION (I&A) in case of request “wildcard”
SSL Server certificate (i.e., valid for all web sites belonging to a
specific domain) or a “multi-host” /”multi-domain” type (i.e., valid for
various web sites, even on
different domains).

Thanks in advance.

Regards,

2011/5/26 Kathleen Wilson <kathle...@yahoo.com>

> On 5/17/11 10:30 AM, Kathleen Wilson wrote:
>

>> Actalis has applied to add the “Actalis Authentication CA G1” root
>> certificate, and turn on the Websites and Code Signing trust bits.
>>
>> Actalis is a public CA offering PKI services to a wide number of
>> customers, mainly banks and local government. Actalis is a Qualified
>> certification service provider according to the EU Signature Directive
>> (Directive 1999/93/EC). Actalis designs, develops, delivers and manages
>> services and solutions for online security, digital signatures and
>> document certification; develops and offers PKI-enabling components,
>> supplies complete digital signature and strong authentication kits
>> (including hardware and software), delivers ICT security consultancy and
>> training.
>>
>> The request is documented in the following bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=520557
>>
>> And in the pending certificates list here:
>> http://www.mozilla.org/projects/security/certs/pending/#Actalis
>>
>> Information Gathering Document:
>> https://bugzilla.mozilla.org/attachment.cgi?id=533004
>>
>> Noteworthy points:
>>
>> * Cert Download URL:
>> https://bugzilla.mozilla.org/attachment.cgi?id=405122
>>
>> * The CPS is provided in Italian and English.
>>
>> CPS for SSL and Code Signing Certs (English):
>>
>> http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLServer_CodeSigning_v2.0.3_EN
>>
>

> Would at least two people please review and comment on this request from

> Actalis to add the “Actalis Authentication CA G1” root certificate, and turn

> on the Websites and Code Signing trust bits?
>
> Kathleen
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Luciano Castro - Actalis]

Jose,

our established procedures for I&A in case of requests for “wildcard”
SSL Server certificates (i.e., valid for all web sites belonging to a
specific domain) or “multi-host” /”multi-domain” type (i.e., valid for
various web sites, even on different domains) are essentially the same
as those for normal SSL Server certificates. In all cases, we
carefully check that the requestor actually owns the domains to be
included in the certificate and that they are an existing organization
based on chamber of commerce records.

Maybe the English translation of our CPS is not fully clear on that;
if needed, we can revise is so to clarify.

Thank in advance for your comments

[Adriano Santoni]

Jose,

Thank you for your comments
Adriano

[Jose Manuel Torres]

Hi all !

Yes, I think English translation of your CPS is not fully clear on that.
Probably you could clarify/explain in next CPS version not only procedures
but some technnical aspects such:

- Maximum number of allowed domains
- if you allow intranet domains and/or only ip addresses , etc..

Regards,

Jose Manuel Torres.

2011/6/1 Adriano Santoni <asant...@gmail.com>

[Kathleen Wilson]

On 5/17/11 10:30 AM, Kathleen Wilson wrote:

> Actalis has applied to add the “Actalis Authentication CA G1” root
> certificate, and turn on the Websites and Code Signing trust bits.
>
> Actalis is a public CA offering PKI services to a wide number of
> customers, mainly banks and local government. Actalis is a Qualified
> certification service provider according to the EU Signature Directive
> (Directive 1999/93/EC). Actalis designs, develops, delivers and manages
> services and solutions for online security, digital signatures and
> document certification; develops and offers PKI-enabling components,
> supplies complete digital signature and strong authentication kits
> (including hardware and software), delivers ICT security consultancy and
> training.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=520557
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Actalis
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=533004
>

All, Would at least one more person review and comment on this request?

So far, one action item has been identified: Actalis to update their CPS
to clarify policies regarding Wildcard SSL certs; including domain
control validation, maximum number of allowed domains, and allowance of
intranet domains and/or IP addresses.

I would also like to ask Actalis about the root directly signing
end-entity certs. While in the past this has been discouraged but
allowed, we are moving in the direction of not allowing end-entity certs
(for customers) to be directly signed by the root. Are there any
technical (or other) barriers that would make it difficult for you to
start using intermediate certificates?

Kathleen

[Adriano.Santoni]

Kathleen,

>> So far, one action item has been identified: Actalis to update their
CPS to clarify policies
>> regarding Wildcard SSL certs; including domain control validation,
maximum number of
>> allowed domains, and allowance of intranet domains and/or IP addresses.

We surely will, but we would like to start revising our CPS once all
change requests have been collected.
Do you (or any other people) believe the above clarifications are all
that is needed in the short term?

>> I would also like to ask Actalis about the root directly signing
end-entity certs.
>> While in the past this has been discouraged but allowed, we are
moving in the
>> direction of not allowing end-entity certs (for customers) to be
directly signed by the root.
>> Are there any technical (or other) barriers that would make it
difficult for you to start using intermediate certificates?

Our existing root CA has *BasicConstraints.pathLenConstraint* set to 0
(zero), so we just cannot have any intermediate CA certificates below
that root. So either you agree on us to keep issuing end entity (SSL
Server) certificate directly from our existing root, or we will have to
regenerate a brand new root. A third option is is that we do both things
(i.e., while we keep on using our existing root, we create a new one,
allowing SubCAs, and schedule a transition within a certain timeframe.
Please advise.

Thank you
Adriano

Il 06/06/2011 23:00, Kathleen Wilson ha scritto:
> On 5/17/11 10:30 AM, Kathleen Wilson wrote:

>> Actalis has applied to add the "Actalis Authentication CA G1" root
>> certificate, and turn on the Websites and Code Signing trust bits.
>>
>> Actalis is a public CA offering PKI services to a wide number of
>> customers, mainly banks and local government. Actalis is a Qualified
>> certification service provider according to the EU Signature Directive
>> (Directive 1999/93/EC). Actalis designs, develops, delivers and manages
>> services and solutions for online security, digital signatures and
>> document certification; develops and offers PKI-enabling components,
>> supplies complete digital signature and strong authentication kits
>> (including hardware and software), delivers ICT security consultancy and
>> training.
>>
>> The request is documented in the following bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=520557
>>
>> And in the pending certificates list here:
>> http://www.mozilla.org/projects/security/certs/pending/#Actalis
>>
>> Information Gathering Document:
>> https://bugzilla.mozilla.org/attachment.cgi?id=533004
>>
>

> All, Would at least one more person review and comment on this request?
>
> So far, one action item has been identified: Actalis to update their
> CPS to clarify policies regarding Wildcard SSL certs; including domain
> control validation, maximum number of allowed domains, and allowance
> of intranet domains and/or IP addresses.
>
> I would also like to ask Actalis about the root directly signing
> end-entity certs. While in the past this has been discouraged but
> allowed, we are moving in the direction of not allowing end-entity
> certs (for customers) to be directly signed by the root. Are there any
> technical (or other) barriers that would make it difficult for you to
> start using intermediate certificates?
>
> Kathleen

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

--
Adriano Santoni
Actalis S.p.A.
www.actalis.it
Skype: asantoni4691

[Eddy Nigg]

On 06/07/2011 03:15 PM, From Adriano.Santoni:

> Our existing root CA has *BasicConstraints.pathLenConstraint* set to 0
> (zero), so we just cannot have any intermediate CA certificates below
> that root.

This is a serious issue indeed!

> So either you agree on us to keep issuing end entity (SSL Server)
> certificate directly from our existing root, or we will have to
> regenerate a brand new root. A third option is is that we do both
> things (i.e., while we keep on using our existing root, we create a
> new one, allowing SubCAs, and schedule a transition within a certain
> timeframe. Please advise.

A slightly different option could be for you to generate a new CA root,
cross-sign the current root and keep issuing from that root. From our
point of view, the current root would become an intermediate CA. Of
course, the new root would have to be included in the software and not
the one you are applying for at the moment.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

[Adriano.Santoni]

I suppose we can do as you suggest, Eddy.

Adriano

Il 07/06/2011 17:13, Eddy Nigg ha scritto:
> On 06/07/2011 03:15 PM, From Adriano.Santoni:

>> Our existing root CA has *BasicConstraints.pathLenConstraint* set to
>> 0 (zero), so we just cannot have any intermediate CA certificates
>> below that root.
>

> This is a serious issue indeed!
>

>> So either you agree on us to keep issuing end entity (SSL Server)
>> certificate directly from our existing root, or we will have to
>> regenerate a brand new root. A third option is is that we do both
>> things (i.e., while we keep on using our existing root, we create a
>> new one, allowing SubCAs, and schedule a transition within a certain
>> timeframe. Please advise.
>

> A slightly different option could be for you to generate a new CA
> root, cross-sign the current root and keep issuing from that root.
> From our point of view, the current root would become an intermediate
> CA. Of course, the new root would have to be included in the software
> and not the one you are applying for at the moment.
>

--

[Peter Gutmann]

Eddy Nigg <eddy...@startcom.org> writes:
>On 06/07/2011 03:15 PM, From Adriano.Santoni:
>> Our existing root CA has *BasicConstraints.pathLenConstraint* set to 0
>> (zero), so we just cannot have any intermediate CA certificates below
>> that root.
>This is a serious issue indeed!

How much software currently pays attention to path-length constraints? When I
last checked, which was admittedly some years ago, you could set it to
anything you wanted without any real loss of ability to have sub-CAs.

Peter.

[Erwann Abalea]

Bonsoir,

Le mardi 7 juin 2011 14:15:20 UTC+2, Adriano.Santoni a écrit :
> >> I would also like to ask Actalis about the root directly signing
> end-entity certs.
> >> While in the past this has been discouraged but allowed, we are
> moving in the
> >> direction of not allowing end-entity certs (for customers) to be
> directly signed by the root.
> >> Are there any technical (or other) barriers that would make it
> difficult for you to start using intermediate certificates?
>
> Our existing root CA has *BasicConstraints.pathLenConstraint* set to 0
> (zero), so we just cannot have any intermediate CA certificates below
> that root.

As Eddy wrote, this is serious. Not necessarily an issue, but surely a serious design problem.
In fact, you *can* have sub-CA certificates, if the verification algorithm follows what is described in X.509 (at least the 2005 edition). This constraint does not apply to the trust anchor at all, and does not apply to any self-signed certificate found in the certification path (see chapter 10 of the recommendation).

Eddy's proposition is clever, though, and should really be taken into consideration.

Of course, in the new root CA, don't specify unneeded constraints ({basic,policy,name}Constraints, certificatePolicies, etc).

--
Erwann.

[Erwann Abalea]

Bonsoir,

Le mardi 7 juin 2011 14:15:20 UTC+2, Adriano.Santoni a écrit :

> >> I would also like to ask Actalis about the root directly signing
> end-entity certs.
> >> While in the past this has been discouraged but allowed, we are
> moving in the
> >> direction of not allowing end-entity certs (for customers) to be
> directly signed by the root.
> >> Are there any technical (or other) barriers that would make it
> difficult for you to start using intermediate certificates?
>
> Our existing root CA has *BasicConstraints.pathLenConstraint* set to 0
> (zero), so we just cannot have any intermediate CA certificates below
> that root.

As Eddy wrote, this is serious. Not necessarily an issue, but surely a serious design problem.

[Adriano.Santoni]

Kathleen,

would you please clarify if you require us to issue certificates from a
SubCA "starting from tomorrow" (assuming we can do so, some way or
another), or is that rather a recommendation that you suggest us to
adhere to in the future, as early as possible: as you can guess, it
makes a lot of a difference for us.

Thank you
Adriano

Il 06/06/2011 23:00, Kathleen Wilson ha scritto:
> On 5/17/11 10:30 AM, Kathleen Wilson wrote:

>> Actalis has applied to add the "Actalis Authentication CA G1" root
>> certificate, and turn on the Websites and Code Signing trust bits.
>>
>> Actalis is a public CA offering PKI services to a wide number of
>> customers, mainly banks and local government. Actalis is a Qualified
>> certification service provider according to the EU Signature Directive
>> (Directive 1999/93/EC). Actalis designs, develops, delivers and manages
>> services and solutions for online security, digital signatures and
>> document certification; develops and offers PKI-enabling components,
>> supplies complete digital signature and strong authentication kits
>> (including hardware and software), delivers ICT security consultancy and
>> training.
>>
>> The request is documented in the following bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=520557
>>
>> And in the pending certificates list here:
>> http://www.mozilla.org/projects/security/certs/pending/#Actalis
>>
>> Information Gathering Document:
>> https://bugzilla.mozilla.org/attachment.cgi?id=533004
>>
>

> All, Would at least one more person review and comment on this request?
>
> So far, one action item has been identified: Actalis to update their
> CPS to clarify policies regarding Wildcard SSL certs; including domain
> control validation, maximum number of allowed domains, and allowance
> of intranet domains and/or IP addresses.
>

> I would also like to ask Actalis about the root directly signing
> end-entity certs. While in the past this has been discouraged but
> allowed, we are moving in the direction of not allowing end-entity
> certs (for customers) to be directly signed by the root. Are there any
> technical (or other) barriers that would make it difficult for you to
> start using intermediate certificates?
>

> Kathleen
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

--

[Kathleen Wilson]

On 6/9/11 8:12 AM, Adriano.Santoni wrote:
> Kathleen,
>
> would you please clarify if you require us to issue certificates from a
> SubCA "starting from tomorrow" (assuming we can do so, some way or
> another), or is that rather a recommendation that you suggest us to
> adhere to in the future, as early as possible: as you can guess, it
> makes a lot of a difference for us.
>

Strictly speaking it is not currently against the Mozilla CA Certificate
Policy to issue certs directly from the root. However, we don't want to
compound the current problem by adding more roots to NSS that directly
sign end-entity certs.

In my opinion, approval of this inclusion request should be contingent
upon having defined a reasonable time frame for moving all new issuance
of end-entity certs under intermediate certs. This means that a solution
needs to be identified and verified as feasible. If the solution
involves creating a new root, then we should modify this request to be
for the new root.

Kathleen

[Adriano.Santoni]

Kathleen,

thank you for clarifying. We will let you know about our timeframe for
moving all new issuance of end-entity certs under intermediate certs. In
the meantime, we are also revising our CPS.

Thank you
Adriano

Il 14/06/2011 01:55, Kathleen Wilson ha scritto:
> On 6/9/11 8:12 AM, Adriano.Santoni wrote:

>> Kathleen,
>>
>> would you please clarify if you require us to issue certificates from a
>> SubCA "starting from tomorrow" (assuming we can do so, some way or
>> another), or is that rather a recommendation that you suggest us to
>> adhere to in the future, as early as possible: as you can guess, it
>> makes a lot of a difference for us.
>>
>

> Strictly speaking it is not currently against the Mozilla CA
> Certificate Policy to issue certs directly from the root. However, we
> don't want to compound the current problem by adding more roots to NSS
> that directly sign end-entity certs.
>
> In my opinion, approval of this inclusion request should be contingent
> upon having defined a reasonable time frame for moving all new
> issuance of end-entity certs under intermediate certs. This means that
> a solution needs to be identified and verified as feasible. If the
> solution involves creating a new root, then we should modify this
> request to be for the new root.
>

[Kathleen Wilson]

On 5/17/11 10:30 AM, Kathleen Wilson wrote:

> Actalis has applied to add the “Actalis Authentication CA G1” root
> certificate, and turn on the Websites and Code Signing trust bits.
>
> Actalis is a public CA offering PKI services to a wide number of
> customers, mainly banks and local government. Actalis is a Qualified
> certification service provider according to the EU Signature Directive
> (Directive 1999/93/EC). Actalis designs, develops, delivers and manages
> services and solutions for online security, digital signatures and
> document certification; develops and offers PKI-enabling components,
> supplies complete digital signature and strong authentication kits
> (including hardware and software), delivers ICT security consultancy and
> training.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=520557
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Actalis
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=533004
>
> Noteworthy points:
>
> * Cert Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=405122
>
> * The CPS is provided in Italian and English.
>
> CPS for SSL and Code Signing Certs (English):
> http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLServer_CodeSigning_v2.0.3_EN
> (PDF document)

Thank you to those of you who have reviewed and commented on this
request. So far two action items have been identified.

1) Actalis to update their CPS to clarify policies regarding Wildcard

SSL certs; including domain control validation, maximum number of
allowed domains, and allowance of intranet domains and/or IP addresses.

2) Actalis to confirm that they can create intermediate certs under this
root, and then specify a time-frame for moving all new issuance of

end-entity certs under intermediate certs.

Are there any further comments/questions regarding this request from

Actalis to add the “Actalis Authentication CA G1” root certificate, and

turn on the Websites and Code Signing trust bits?

Kathleen

[Adriano.Santoni]

About action point #1: we have revised our CPS according to your
requests, and published it at
http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLserver_CodeSigning_v2.0.4_EN

Please confirm that you are happy with it.

Next, we will let you know our answer to action point #2.

Thank you
Adriano

Il 14/06/2011 19:50, Kathleen Wilson ha scritto:
> On 5/17/11 10:30 AM, Kathleen Wilson wrote:

> Thank you to those of you who have reviewed and commented on this
> request. So far two action items have been identified.
>
> 1) Actalis to update their CPS to clarify policies regarding Wildcard
> SSL certs; including domain control validation, maximum number of
> allowed domains, and allowance of intranet domains and/or IP addresses.
>
> 2) Actalis to confirm that they can create intermediate certs under
> this root, and then specify a time-frame for moving all new issuance
> of end-entity certs under intermediate certs.
>

> Are there any further comments/questions regarding this request from

> Actalis to add the "Actalis Authentication CA G1" root certificate,

> and turn on the Websites and Code Signing trust bits?

[Kathleen Wilson]

On 6/15/11 8:53 AM, Adriano.Santoni wrote:
> About action point #1: we have revised our CPS according to your
> requests, and published it at
> http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLserver_CodeSigning_v2.0.4_EN
>
>
> Please confirm that you are happy with it.
>

To view the document at the link above, I downloaded it and then added
..pdf to the file name.

Here’s the text from the updated sections.
--
3.1 Naming rules

The subject field of the certificate must contain information which is
easy to understand and allows the subscriber organisation of the
certificate to be identified. Pseudonyms or alternative names to the
company name (or other official name) of the Client are not allowed.

The country component in the subject field must contain the ISO 3166
two-letter code (e.g. “IT” for Italy) which identifies the country to
which the subscriber organisation of the certificate belongs.

The organizatioName component of the field must contain the official
name (i.e. company name) of the certificate subscriber organisation. The
name must be unique and not lead to ambiguity. In order to resolve a
possible ambiguity, the CA may request that the name is followed by the
tax code of the organisation or other useful information.

In the case of an SSL Server certificate, the commonName component of
the subject field must con-tain the correct web server address (numeric
or symbolic). A valid example is “www.example.com”. Another valid
example is “109.70.240.125” (public IP address). Private IP addresses
are not allowed.

In the case of a Code Signing certificate, the commonName component of
the subject field may con-tain any phrase whatsoever, proposed by the
applicant, provided that it cannot lead Relying Parties to mistake the
identity of the subscriber and the objectives/functionality of the
signed software. A valid example is “ACME Code Signing”.

The Clients shall not be able to use names in the certificate
applications which violate the intellectual property rights of others.
Actalis shall not be involved in any controversy whatsoever concerning
the copyright of domain names, commercial names, commercial trademarks
or services. Actalis reserves the right to reject the certificate
application (or revoke an already issued certificate) in case of such a
controversy.

4.1 Certificate application

The certificate application may take place in two different ways:
• by filling-out and submitting the on-line application form on the CA
web site https://portal.actalis.it
• by filling-out and sending the application form to the CA (via fax,
e-mail, ordinary mail).

The certificate application shall at least include the following
information:
• details of applicant organisation
• personal and contact details (e-mail, telephone) of applicant
• personal and contact details (e-mail, telephone) of a “technical
reference”
• address of the web site to be included in the certificate (for the SSL
Server certificates)
• value proposed for commonName field (for Code Signing certificates)

The certificate application must be accompanied by the CSR (Certificate
Signing Request). In the case of an application on paper, the CSR can be
subsequently sent to the CA via electronic mail, to the ad-dress
provided by the registration manager.

The CSR is normally generated by the applicant organisation by its own
means.

It is also possible to request a “wildcard” SSL Server certificate
(i.e., valid for all web sites belonging to a specific domain) or a
multi-SAN SSL Server certificate (wherein two or more SAN values are
pre-sent specifying several hostnames and/or domain names for which the
same certificate will be used). In such cases, the same I&A procedures
apply: the CA always checks that the requestor actually owns the domains
and/or IP addresses to be included in the certificate and that the
requestor is an existing organization based on latest chamber of
commerce records.

Wildcard and multi-SAN SSL Server certificates are subject to different
fees than those for plain certifi-cates (i.e. single web site). For
further information please contact Actalis’ sales department.

The maximum number of SAN values allowed in an SSL Server certificate is
100.
--

Kathleen

[Jose Manuel Torres]

Hi all !!

The explanation about Wildcard and multi-SAN SSL certificate is OK for me.

Regards,

2011/6/15 Kathleen Wilson <kathle...@yahoo.com>

> On 6/15/11 8:53 AM, Adriano.Santoni wrote:
>

>> About action point #1: we have revised our CPS according to your
>> requests, and published it at
>>
>> http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLserver_CodeSigning_v2.0.4_EN
>>
>>
>> Please confirm that you are happy with it.
>>
>>
>

[Adriano.Santoni]

Following up my last post, here is our feedback on action point #2.

We cannot generate a SubCA under our current (self-signed) CA, first
because our CMS platform does not allow, second because - at any rate -
that would infringe RFC 5280 (because of pathLenConstraint=0 being set
in our current CA certificate).

We also believe it would be messy and probably ineffective to
cross-certificate our current CA with a new root, thereby making it
"look" like a SubCA, because our current (self-signed) CA is already
trusted in Windows (see link below) and so we would end up with
different browsers having to validate different chains.

http://social.technet.microsoft.com/wiki/contents/articles/windows-root-certificate-program-members-list-all-cas.aspx

Therefore, we propose the following:
- let us follow the regular process for the remainder of the inclusion
of the current root
- we commit to create a new CA hierarchy (root + subca) and start using
it within a certain timeframe
- we also open a new root inclusion request (new Bugzilla entry) for the
new root above

Do you agree?

Thank you
Adriano

Il 15/06/2011 17:53, Adriano.Santoni ha scritto:
> About action point #1: we have revised our CPS according to your
> requests, and published it at
> http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLserver_CodeSigning_v2.0.4_EN
>
>
> Please confirm that you are happy with it.
>

> Next, we will let you know our answer to action point #2.
>
> Thank you
> Adriano
>
>
>
> Il 14/06/2011 19:50, Kathleen Wilson ha scritto:
>> On 5/17/11 10:30 AM, Kathleen Wilson wrote:

>> Thank you to those of you who have reviewed and commented on this
>> request. So far two action items have been identified.
>>
>> 1) Actalis to update their CPS to clarify policies regarding Wildcard
>> SSL certs; including domain control validation, maximum number of
>> allowed domains, and allowance of intranet domains and/or IP addresses.
>>
>> 2) Actalis to confirm that they can create intermediate certs under
>> this root, and then specify a time-frame for moving all new issuance
>> of end-entity certs under intermediate certs.
>>

>> Are there any further comments/questions regarding this request from

>> Actalis to add the "Actalis Authentication CA G1" root certificate,

>> and turn on the Websites and Code Signing trust bits?

>>
>> Kathleen
>>
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>

--

[Rob Stradling]

On Friday 17 Jun 2011 11:08:03 Adriano.Santoni wrote:
> Following up my last post, here is our feedback on action point #2.
>
> We cannot generate a SubCA under our current (self-signed) CA, first
> because our CMS platform does not allow, second because - at any rate -
> that would infringe RFC 5280 (because of pathLenConstraint=0 being set
> in our current CA certificate).
>
> We also believe it would be messy and probably ineffective to
> cross-certificate our current CA with a new root, thereby making it
> "look" like a SubCA, because our current (self-signed) CA is already
> trusted in Windows (see link below) and so we would end up with
> different browsers having to validate different chains.
>
> http://social.technet.microsoft.com/wiki/contents/articles/windows-root-cer
> tificate-program-members-list-all-cas.aspx

Adriano, are you aware of this Microsoft requirement [1]:

"2. All root certificates distributed by the Program must be maintained in an
offline state – that is, root certificates may not issue end-entity certificates
of any kind, except as explicitly approved from Microsoft.
There are limited scenarios for direct issuance of end-entity certificate from
a root certificate: for example, special configurations may exist to provision
certain types of hardware, and the CAs can account for the security of the
root certificate in such scenarios. However, issuance of code signing or SSL
certificates directly from an online root certificate is prohibited. Program CAs
must disclose any scenario where they issue end-entity certificates directly
from root certificates distributed by the Program, and receive specific approval
from Microsoft."

Since you are a member of the Microsoft Root Certificate Program, presumably
you will already be effectively prohibited from issuing end-entity certificates
directly from a Root Certificate. If so, there seems little point in asking
Mozilla to allow you to issue end-entity certificates directly from a Root
Certificate unless you are already planning to exit the Microsoft Root
Certificate Program.

If, on the other hand, Microsoft have granted you special permission to
continue issuing end-entity certificates directly from your Root Certificates,
I'd be interested to hear about it.

[1] http://social.technet.microsoft.com/wiki/contents/articles/windows-root-
certificate-program-technical-requirements.aspx

<snip>

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Adriano.Santoni]

Yes, we are aware of that.

The MS rules you quoted were different at the time when we submitted our
root CA to them.
We will conform to the new MS rules according to a migration plan that
we discuss with them.

Adriano

Il 17/06/2011 13:17, Rob Stradling ha scritto:
> On Friday 17 Jun 2011 11:08:03 Adriano.Santoni wrote:
>> Following up my last post, here is our feedback on action point #2.
>>
>> We cannot generate a SubCA under our current (self-signed) CA, first
>> because our CMS platform does not allow, second because - at any rate -
>> that would infringe RFC 5280 (because of pathLenConstraint=0 being set
>> in our current CA certificate).
>>
>> We also believe it would be messy and probably ineffective to
>> cross-certificate our current CA with a new root, thereby making it
>> "look" like a SubCA, because our current (self-signed) CA is already
>> trusted in Windows (see link below) and so we would end up with
>> different browsers having to validate different chains.
>>
>> http://social.technet.microsoft.com/wiki/contents/articles/windows-root-cer
>> tificate-program-members-list-all-cas.aspx
> Adriano, are you aware of this Microsoft requirement [1]:
>
> "2. All root certificates distributed by the Program must be maintained in an

> offline state -- that is, root certificates may not issue end-entity certificates

> of any kind, except as explicitly approved from Microsoft.
> There are limited scenarios for direct issuance of end-entity certificate from
> a root certificate: for example, special configurations may exist to provision
> certain types of hardware, and the CAs can account for the security of the
> root certificate in such scenarios. However, issuance of code signing or SSL
> certificates directly from an online root certificate is prohibited. Program CAs
> must disclose any scenario where they issue end-entity certificates directly
> from root certificates distributed by the Program, and receive specific approval
> from Microsoft."
>
> Since you are a member of the Microsoft Root Certificate Program, presumably
> you will already be effectively prohibited from issuing end-entity certificates
> directly from a Root Certificate. If so, there seems little point in asking
> Mozilla to allow you to issue end-entity certificates directly from a Root
> Certificate unless you are already planning to exit the Microsoft Root
> Certificate Program.
>
> If, on the other hand, Microsoft have granted you special permission to
> continue issuing end-entity certificates directly from your Root Certificates,
> I'd be interested to hear about it.
>
> [1] http://social.technet.microsoft.com/wiki/contents/articles/windows-root-
> certificate-program-technical-requirements.aspx
>
> <snip>
>
> Rob Stradling

> Senior Research& Development Scientist

> COMODO - Creating Trust Online

--

[Erwann Abalea]

Le vendredi 17 juin 2011 12:08:03 UTC+2, Adriano.Santoni a écrit :
> Following up my last post, here is our feedback on action point #2.
>
> We cannot generate a SubCA under our current (self-signed) CA, first
> because our CMS platform does not allow, second because - at any rate -
> that would infringe RFC 5280 (because of pathLenConstraint=0 being set
> in our current CA certificate).

That would not infringe neither RFC5280 nor the X.509 standard. If you carefully read RFC5280, chapter 6.1 (Basic Path Validation), you find this:

-----
To meet this goal, the path validation process verifies, among other
things, that a prospective certification path (a sequence of n
certificates) satisfies the following conditions:

(a) for all x in {1, ..., n-1}, the subject of certificate x is
the issuer of certificate x+1;

(b) certificate 1 is issued by the trust anchor;

(c) certificate n is the certificate to be validated (i.e., the
target certificate); and

(d) for all x in {1, ..., n}, the certificate was valid at the
time in question.

A certificate MUST NOT appear more than once in a prospective
certification path.

When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path. Information about trust anchors
is provided as inputs to the certification path validation algorithm
(Section 6.1.1).
-----

So the BasicConstraints extension's content is not checked for the Trust Anchor (other constraints are not checked either: certificatePolicies, nameConstraints, ...).

Following these rules, you could sign a sub-CA, with whatever pathLenConstraint you want.

The X.509 standard (chapter 10) is phrased differently, but the result is the same.

You can't be sure that deployed software strictly follow the rules, though.

--
Erwann.

[Erwann Abalea]

Le vendredi 17 juin 2011 12:08:03 UTC+2, Adriano.Santoni a écrit :

> Following up my last post, here is our feedback on action point #2.
>
> We cannot generate a SubCA under our current (self-signed) CA, first
> because our CMS platform does not allow, second because - at any rate -
> that would infringe RFC 5280 (because of pathLenConstraint=0 being set
> in our current CA certificate).

That would not infringe neither RFC5280 nor the X.509 standard. If you carefully read RFC5280, chapter 6.1 (Basic Path Validation), you find this:

[Jean-Marc Desperrier]

Erwann Abalea wrote:
> Le vendredi 17 juin 2011 12:08:03 UTC+2, Adriano.Santoni a �crit :

>> Following up my last post, here is our feedback on action point #2.
>>
>> We cannot generate a SubCA under our current (self-signed) CA, first
>> because our CMS platform does not allow,

As in Netscape/iPlanet Certificate Management System ?? Oh, maybe
Entrust also uses the CMS abbreviation.

>> second because - at any rate -
>> that would infringe RFC 5280 (because of pathLenConstraint=0 being set
>> in our current CA certificate).
>
> That would not infringe neither RFC5280 nor the X.509 standard. If you carefully read RFC5280, chapter 6.1 (Basic Path Validation), you find this:

> [...]

> You can't be sure that deployed software strictly follow the rules, though.

I don't remember where exactly this is written, but one is *allowed* to
extend the path validation algorithm with further restriction, and to
load the initial state from some outside data source. Including the
content of the root certificate.

So implementations that do use the content of root certificate to
restrict the validation, including for example it's "Not Before" and
"Not After" field, are not strictly talking breaking the rule.

Here the solution is regenerate the root certificate without the path
length constraint, which is not a that terrible things to do when you
keep the same private key.

[Jean-Marc Desperrier]

Adriano.Santoni wrote:
> We will conform to the new MS rules according to a migration plan that
> we discuss with them.

My personal opinion is that Mozilla should wait until that migration
plan is completed to further discuss the inclusion of the Actalis root.

I'm afraid Adriano that opinion will be shared by a majority here.
Knowing that the final word ultimately belongs to Kathleen and other
employees of Mozilla. But really I don't believe Mozilla will want to
include the current version and some time later update it with the new one.

[Kathleen Wilson]

On 6/17/11 3:08 AM, Adriano.Santoni wrote:
> Following up my last post, here is our feedback on action point #2.

> ...

> Therefore, we propose the following:
> - let us follow the regular process for the remainder of the inclusion
> of the current root
> - we commit to create a new CA hierarchy (root + subca) and start using
> it within a certain timeframe
> - we also open a new root inclusion request (new Bugzilla entry) for the
> new root above
>

I am glad to see that folks are continuing to provide constructive
feedback/suggestions on this. Please continue to do so, as I believe it
is good for Actalis (and other CAs in the same situation) to consider
the various options in order to determine the best long-term solution
for them.

This solution that Actalis has proposed is acceptable according to the
current Mozilla CA Certificate Policy. If there are no additional
questions/concerns to be addressed, then we can move forward to the
approval phase of this request after Actalis has stated their commitment
to introducing the new root, creating the corresponding new Bugzilla
entry, and moving to the new hierarchy in a timely manner. I will then
track the action item regarding the new root separately.

Once the Mozilla CA Certificate Policy is updated to include this
requirement (or the corresponding CAB Forum Baseline Requirement) I will
have a project to work with the CAs with roots in NSS that directly sign
subscriber certs to update their hierarchies. The CAs with roots that
directly sign subscriber certs (that I know of) are noted in the
included and pending web pages -- search for "directly" in each page.
http://www.mozilla.org/projects/security/certs/included/
http://www.mozilla.org/projects/security/certs/pending/

Kathleen

[Jean-Marc Desperrier]

Kathleen Wilson wrote:
> The maximum number of SAN values allowed in an SSL Server certificate is
> 100.

One hundred SAN values seems a bit too much. I believe there was some
testing about what the maximum that works reliably is, but I don't
remember the results exactly.

[Gordon...@wellsfargo.com]

What document is specifies max# of SANs?

Thank you,

~Gordon

-Gordon
Gordon Young
Public Key Infrastructure (PKI) Engineering
Cryptographic Services|IST|TGS|TOG|Wells Fargo
(480) 437-7798 Voice
gordon...@wellsfargo.com

This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.

-----Original Message-----
From: dev-security-policy-bounces+gordon.young=wellsfa...@lists.mozilla.org [mailto:dev-security-policy-bounces+gordon.young=wellsfa...@lists.mozilla.org] On Behalf Of Jean-Marc Desperrier
Sent: Friday, June 17, 2011 10:28 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Actalis Root Inclusion Request

Kathleen Wilson wrote:
> The maximum number of SAN values allowed in an SSL Server certificate
> is 100.

One hundred SAN values seems a bit too much. I believe there was some testing about what the maximum that works reliably is, but I don't remember the results exactly.

[Erwann Abalea]

A certificate, when used in TLS, cannot excess 2^24-1 bytes. In fact, it's a little less, since it is included in several structures, and the final message itself cannot be larger than 2^24-1 bytes.

In practice, some implementations have been tested to fail if the certificate is bigger than 2^14 bytes (16kB), size of a TLS fragment.

I don't see a problem with 100 SAN values, if a limit needs to be set.

--
Erwann.

[Erwann Abalea]

Le vendredi 17 juin 2011 19:27:53 UTC+2, Jean-Marc Desperrier a écrit :

A certificate, when used in TLS, cannot excess 2^24-1 bytes. In fact, it's a little less, since it is included in several structures, and the final message itself cannot be larger than 2^24-1 bytes.

[Gordon...@wellsfargo.com]

Erwann,

I wanted to share my experience with IPsec and certificate size. In practical application the size limit of ASN.1Cert<>
Is even less than TLS. I saw IKEv2 failures when certificates where greater than 1k. This means stripping many v3 extensions to keep the size down.

~Gordon

-----Original Message-----
From: dev-security-policy-bounces+gordon.young=wellsfa...@lists.mozilla.org [mailto:dev-security-policy-bounces+gordon.young=wellsfa...@lists.mozilla.org] On Behalf Of Erwann Abalea
Sent: Monday, June 20, 2011 1:05 AM
To: mozilla.dev.s...@googlegroups.com
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re : Re: Actalis Root Inclusion Request

Le vendredi 17 juin 2011 19:27:53 UTC+2, Jean-Marc Desperrier a écrit :

A certificate, when used in TLS, cannot excess 2^24-1 bytes. In fact, it's a little less, since it is included in several structures, and the final message itself cannot be larger than 2^24-1 bytes.

In practice, some implementations have been tested to fail if the certificate is bigger than 2^14 bytes (16kB), size of a TLS fragment.

I don't see a problem with 100 SAN values, if a limit needs to be set.

--
Erwann.

[Gervase Markham]

On 17/06/11 18:30, Jean-Marc Desperrier wrote:
> My personal opinion is that Mozilla should wait until that migration
> plan is completed to further discuss the inclusion of the Actalis root.

I think that we should be looking at our own requirements, not those of
others, and we should not impose requirements before we have them, even
if we think they are coming.

If Actalis know they need to transition, and know that if/when the CAB
Forum Baseline Requirements become binding on CAs as part of an audit,
this won't be allowed any more, and _still_ want to go ahead, I don't
think we should treat them differently.

Gerv

[Ian G]

On 21/06/11 6:54 AM, Gervase Markham wrote:
> On 17/06/11 18:30, Jean-Marc Desperrier wrote:

>> My personal opinion is that Mozilla should wait until that migration
>> plan is completed to further discuss the inclusion of the Actalis root.
>

> I think that we should be looking at our own requirements, not those of
> others, and we should not impose requirements before we have them, even
> if we think they are coming.
>
> If Actalis know they need to transition, and know that if/when the CAB
> Forum Baseline Requirements become binding on CAs as part of an audit,
> this won't be allowed any more, and _still_ want to go ahead, I don't
> think we should treat them differently.

+1

iang

[Kathleen Wilson]

On 5/17/11 10:30 AM, Kathleen Wilson wrote:

> Actalis has applied to add the �Actalis Authentication CA G1� root

> certificate, and turn on the Websites and Code Signing trust bits.
>
> Actalis is a public CA offering PKI services to a wide number of
> customers, mainly banks and local government. Actalis is a Qualified
> certification service provider according to the EU Signature Directive
> (Directive 1999/93/EC). Actalis designs, develops, delivers and manages
> services and solutions for online security, digital signatures and
> document certification; develops and offers PKI-enabling components,
> supplies complete digital signature and strong authentication kits
> (including hardware and software), delivers ICT security consultancy and
> training.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=520557
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Actalis
>
> Information Gathering Document:
> https://bugzilla.mozilla.org/attachment.cgi?id=533004
>
> Noteworthy points:
>
> * Cert Download URL: https://bugzilla.mozilla.org/attachment.cgi?id=405122
>
> * The CPS is provided in Italian and English.
>
> CPS for SSL and Code Signing Certs (English):
> http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLServer_CodeSigning_v2.0.3_EN
>
> (PDF document)
>
>

> * This �Actalis Authentication CA G1� root certificate directly signs
> end-entity certificates for SSL and Code Signing. Technical security
> controls are described in section 6 of the CPS, and Actalis has a
> detailed Security Plan in place that is reviewed by their national
> supervising authority (CNIPA).

Again, Thank you to those of you who have reviewed and commented on this
request. Two action items have been identified.

1) Actalis updated the English version of their CPS to clarify policies
regarding Wildcard SSL certs:
http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLserver_CodeSigning_v2.0.4_EN

Actalis will also need to update the Italian version of the document.

2) Actalis intends to create a new CA hierarchy (root + subca), create a
new root inclusion request (bugzilla entry), and plan migration from the
current root to this new root. This action item will be tracked separately.

If there are no further comments regarding this root inclusion request
from Actalis, then I will close this discussion. After I have confirmed
that the changes to the Italian version of their CPS have been posted on
the Actalis website (re action item #1), I will recommend approval in
the bug.

Kathleen

[Jean-Marc Desperrier]

Gervase Markham wrote:
> If Actalis know they need to transition, and know that if/when the CAB
> Forum Baseline Requirements become binding on CAs as part of an audit,

> this won't be allowed any more, and_still_ want to go ahead, I don't

> think we should treat them differently.

I don't believe for one second that CAs that are already included will
be disabled when this become binding.

In practice, this means that Mozilla will have to hurry up to consider
Actalis's new application (at the expense of other CA waiting for their
request to be exmined), or allow it for longer to issue certificates
from the root.

The contention in the examination of CA's requests is an important
factor why I have this opinion.
As well as the fact I consider issuing certificates from the root ought
to be forbidden *right* *now* : The current news show that CA are
confronted with stronger and stronger attacks on their infrastructure.
The thought of what might happen if a smart attacker gets, even
temporarily, the control of the root key of a CA that has issued a large
number of certificates is very worrying.

[Jean-Marc Desperrier]

Kathleen Wilson wrote:
> 2) Actalis intends to create a new CA hierarchy (root + subca), create a
> new root inclusion request (bugzilla entry), and plan migration from the
> current root to this new root. This action item will be tracked separately.

How much work will represent the switch to the new root for Mozilla ?
I'm worried the current work will have to be redone in a short time
frame because of the change. If Microsoft will require Actalis to change
it's root certificate within less than a year, I'm not convinced getting
the current version in is a good idea.

[Gervase Markham]

On 23/06/11 09:25, Jean-Marc Desperrier wrote:
> I don't believe for one second that CAs that are already included will
> be disabled when this become binding.

If the BRs become part of audit requirements, then the CAs will
eventually fail their audits. If a CA fails its audit, it will be removed.

> In practice, this means that Mozilla will have to hurry up to consider
> Actalis's new application (at the expense of other CA waiting for their
> request to be exmined), or allow it for longer to issue certificates
> from the root.

I don't believe we intend to speed up Actalis' application for this purpose.

> As well as the fact I consider issuing certificates from the root ought
> to be forbidden *right* *now* : The current news show that CA are
> confronted with stronger and stronger attacks on their infrastructure.
> The thought of what might happen if a smart attacker gets, even
> temporarily, the control of the root key of a CA that has issued a large
> number of certificates is very worrying.

It is. But changing the rules out from under people, or applying them
selectively, is not fair.

If you want to propose a change to the Mozilla requirements, in advance
of the BRs coming into force, go right ahead.

Gerv

[Gervase Markham]

On 23/06/11 09:28, Jean-Marc Desperrier wrote:
> How much work will represent the switch to the new root for Mozilla ?

Given that we have recently examined their policies and practices,
presumably not much. There will be a delay before the root achieves
ubiquity, of course - but that's their problem.

Gerv

[Adriano.Santoni]

We have just published the updated ITalian version of our CPS:

http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_certificati_SSL_server_e_Code_Signing_v2.0.4_IT.pdf

Thank you,
Adriano

Il 22/06/2011 20:32, Kathleen Wilson ha scritto:
> On 5/17/11 10:30 AM, Kathleen Wilson wrote:

>> Actalis has applied to add the "Actalis Authentication CA G1" root

>> certificate, and turn on the Websites and Code Signing trust bits.
>>
>> Actalis is a public CA offering PKI services to a wide number of
>> customers, mainly banks and local government. Actalis is a Qualified
>> certification service provider according to the EU Signature Directive
>> (Directive 1999/93/EC). Actalis designs, develops, delivers and manages
>> services and solutions for online security, digital signatures and
>> document certification; develops and offers PKI-enabling components,
>> supplies complete digital signature and strong authentication kits
>> (including hardware and software), delivers ICT security consultancy and
>> training.
>>
>> The request is documented in the following bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=520557
>>
>> And in the pending certificates list here:
>> http://www.mozilla.org/projects/security/certs/pending/#Actalis
>>
>> Information Gathering Document:
>> https://bugzilla.mozilla.org/attachment.cgi?id=533004
>>
>> Noteworthy points:
>>
>> * Cert Download URL:
>> https://bugzilla.mozilla.org/attachment.cgi?id=405122
>>
>> * The CPS is provided in Italian and English.
>>
>> CPS for SSL and Code Signing Certs (English):
>> http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLServer_CodeSigning_v2.0.3_EN
>>
>>
>> (PDF document)
>>
>>

>> * This "Actalis Authentication CA G1" root certificate directly signs

>> end-entity certificates for SSL and Code Signing. Technical security
>> controls are described in section 6 of the CPS, and Actalis has a
>> detailed Security Plan in place that is reviewed by their national
>> supervising authority (CNIPA).
>
>
> Again, Thank you to those of you who have reviewed and commented on
> this request. Two action items have been identified.
>
> 1) Actalis updated the English version of their CPS to clarify
> policies regarding Wildcard SSL certs:
> http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLserver_CodeSigning_v2.0.4_EN
>
> Actalis will also need to update the Italian version of the document.
>

> 2) Actalis intends to create a new CA hierarchy (root + subca), create
> a new root inclusion request (bugzilla entry), and plan migration from
> the current root to this new root. This action item will be tracked
> separately.
>

> If there are no further comments regarding this root inclusion request
> from Actalis, then I will close this discussion. After I have
> confirmed that the changes to the Italian version of their CPS have
> been posted on the Actalis website (re action item #1), I will
> recommend approval in the bug.
>
> Kathleen
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

--

[Kathleen Wilson]

On 6/23/11 5:41 AM, Adriano.Santoni wrote:
> We have just published the updated ITalian version of our CPS:
>
> http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_certificati_SSL_server_e_Code_Signing_v2.0.4_IT.pdf
>
>
> Thank you,
> Adriano
>

I have confirmed that the changes that were made to the English version
of the CPS regarding wildcard SSL certs have also been made to the
Italian version of the document, and both updated documents are
available from the Actalis website:

http://portal.actalis.it/Info/cmsContent?cmsRef=actalis/Info/Manuali

Kathleen

[Kathleen Wilson]

On 5/17/11 10:30 AM, Kathleen Wilson wrote:

> Actalis has applied to add the �Actalis Authentication CA G1� root

> certificate, and turn on the Websites and Code Signing trust bits.
>

Thank you to those of you who reviewed this root inclusion request from
Actalis and contributed to this discussion. The result of this
discussion is that Actalis updated their CPS to clarify their policies
regarding wildcard SSL certs, and Actalis plans to create a new CA
hierarchy with intermediate certificates.

I will track the remaining action item in the bug, separate from
approval/inclusion of this root.

ACTION Actalis: Create a new CA hierarchy (root + subca), create a new
root inclusion request (bugzilla entry), and begin migration from the

current root to this new root.

This concludes the public discussion about Actalis's request to add the
�Actalis Root Certification Authority� root certificate and enable the
Websites and Email trust bits.

I will post my recommendation for approval of this request in the bug.

https://bugzilla.mozilla.org/show_bug.cgi?id=520557

All follow-up on this request should be posted directly in the bug.

Thanks again to all of you who have participated in this discussion.

Kathleen

[Kathleen Wilson]

Correction: This concludes the public discussion about Actalis's request

to add the �Actalis Authentication CA G1� root certificate, and turn on
the Websites and Code Signing trust bits.

Kathleen