520557 - Add Actalis Authentication Root CA certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Root Program, task)

Description

[Adriano Santoni]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.0.13) Gecko/2009073022 Firefox/3.0.13 (.NET CLR 3.5.30729)
Build Identifier: 

Full information about this application is contained in the attached document.

Reproducible: Always

Comment 1

[Adriano Santoni]

Attachment: Details about our application for the Mozilla Root CA Program

The attached Word document provides details about our application for the Mozilla Root CA Program.

Comment 2

[Adriano Santoni]

Attachment: Root certificate

I forgot to attach the root certificate we'd like to be included in Mozilla software.

Comment 3

[Kathleen Wilson]

Starting the information gathering and verification phase as per
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

Comment 4

[Kathleen Wilson]

Attachment: Root Cert Der Format

Comment 5

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

The attached document summarizes the information that has been gathered and
verified for this request. The items highlighted in yellow indicate where
further information or clarification is needed. Please review the full document
for accuracy and completeness.

Comment 6

[Adriano Santoni]

(In reply to comment #5)
> Created an attachment (id=405304) [details]
> Initial Information Gathering Document
> The attached document summarizes the information that has been gathered and
> verified for this request. The items highlighted in yellow indicate where
> further information or clarification is needed. Please review the full document
> for accuracy and completeness.

Could you please re-attach your document in an editable format, so I can include my answers directly into it ?

Comment 7

[Kathleen Wilson]

Attachment: Editable Initial Info Gathering Doc

Comment 8

[Adriano Santoni]

(In reply to comment #7)
> Created an attachment (id=405505) [details]
> Editable Initial Info Gathering Doc

Kathleen, I am attaching here:
1) a revision of your document, with (hopefully) all the answers and clarifications you requested.
2) the last CNIPA auduting report

I remain waiting for your next feedback.

Comment 9

[Adriano Santoni]

Attachment: atachment revised

Comment 10

[Adriano Santoni]

Attachment: CNIPA audit of May 22, 2008

Comment 11

[Kathleen Wilson]

Thank you for the information and for translating your CPS into English.

> This CA directly issues end-entity certificates

As noted in our problematic practices document (https://wiki.mozilla.org/CA:Problematic_Practices), we think that issuing end-entity certificates directly from a root is not a good practice, and that a better practice would be to issue EE certificates from a subordinate CA that can act as the issuing CA. However there is nothing in our current CA policy that prohibits issuing EE certificates directly from a root.

> CPS for the email (S/MIME) certs.
> Not available yet. 
> We plan to use this CA also for S/MIME certs in the next future.

My recommendation is that we proceed with the websites and code signing trust bits. When you are ready, you can create a new bug to enable the email trust bit

> Audit

This root was created after the audit took place. Before inclusion we will need the next audit that includes this root. However, we can proceed based on the current audit for now. (https://wiki.mozilla.org/CA:How_to_apply#Timeline)

> If you want, I can also send you a statement from an independent party 
> that those guidelines are based on the ETSI TS 101 456 criteria.

I don’t think that will be necessary, because the CNIPA surveillance guidelines document says: “These Guidelines are structured in accordance with the schedule of the technical specifications ETSI TS 101 456 and ETSI Technical Report TR 102 437.”

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

Are the external RA’s audited? By who? Frequency? Criteria?

> Certificates referencing hostnames or private IP addresses
CPS Section 3.4: In the case when a private IP address is requested to be included in the SSL Server certificate (i.e. one that cannot reached from the public Internet network), the CA does not verify the correctness of that address.

Please see https://wiki.mozilla.org/CA:Problematic_Practices#Certificates_referencing_hostnames_or_private_IP_addresses 
What steps are taken to mitigate the risks associated with issuing SSL certs for private IP addresses?

Comment 12

[Adriano Santoni]

(In reply to comment #11)

>> Are the external RA’s audited? By who? Frequency? Criteria?

Yes, they are audited by us. There is no fixed schedule for such auditing. At least once per year we choose randomly some of our RAs and arrange an auditing meeting with them. We verify that the RA actually operates as mandated by our RA agreement. If anything wrong is found, we request the RA to take corrective actions quickly. Should they fail to, their RA credentials would be revoked and they would be stopped from acting as our RA anymore. In the worst case, should any material damage be suffered by us because of RA misbehavior, we could ask to be indemnified. This has never happened so far. If you so require, I can let you see our RA contract on a confidential basis.

>> What steps are taken to mitigate the risks associated with issuing SSL certs
for private IP addresses?

We do not actually issue SSL certificates with private IP address in them. That was a leftover in our SSL certs CPS, not mean to be there. We have corrected the CPS, removing any mention to private IP addresses. Please check our revised CPS v2.0.2 in both Italian and English at the following URL:

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

Comment 13

[Kathleen Wilson]

Thank you for the information.

In reviewing the RA requirements in more detail, section 4.2 of the CPS mentions that the RA must perform the identification verification as per section 3.2. However, it doesn't mention the need for the RA to perform the domain name verification steps as outlined in section 3.3. Was this an oversight? Can it be added?

Would it be possible to add information to the CPS about how the RA requirements are monitored/audited as per your comment in Comment #12?

Comment 14

[Adriano Santoni]

(In reply to comment #13)
> Thank you for the information.
> In reviewing the RA requirements in more detail, section 4.2 of the CPS
> mentions that the RA must perform the identification verification as per
> section 3.2. However, it doesn't mention the need for the RA to perform the
> domain name verification steps as outlined in section 3.3. Was this an
> oversight? Can it be added?

Yes, it was indeed an oversight. See below.

> Would it be possible to add information to the CPS about how the RA
> requirements are monitored/audited as per your comment in Comment #12?

Yes. I have revised our CPS, fixing the oversight above and adding clarifications about RAs. I also updated our address and other details. Please see version 2.0.3 of our CPS at the following URL:

http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_SSLServer_CodeSigning_v2.0.3_EN

Both Italian and English versions can be found at the following URL:

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

Comment 15

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 16

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about one week. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may sit in the discussion for
weeks. When there are not enough people contributing to the discussions ahead
of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 17

[Kathleen Wilson]

This request is approaching the top of the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

As such, I am re-reviewing the information. Please provide the following:

1) Most recent audit statement.

2) Attach to this bug, in PDF form, the English version of the CPS for SSL and Code Signing Certs. I do not want to download Actalis' File Protector desktop application to read Actalis' CPS. 

3) My notes indicate that you had planned to release an OCSP service. Is it available now?  If yes, please provide a url to a test website whose SSL cert has the OCSP URI in the AIA.

Comment 18

[Adriano Santoni]

(In reply to comment #17)

> Please provide the following:
> 1) Most recent audit statement.

Find it attached. It still the one of November 2009, as we are audited every 18 months by our national supervising authority (formerly known as CNIPA, now DigitPA).

> 2) Attach to this bug, in PDF form, the English version of the CPS for SSL and
> Code Signing Certs. I do not want to download Actalis' File Protector desktop
> application to read Actalis' CPS.

Find our CPS attached (I do not understand your reference to our desktop application).

> 3) My notes indicate that you had planned to release an OCSP service. Is it
> available now?  If yes, please provide a url to a test website whose SSL cert
> has the OCSP URI in the AIA.

I will check and reply to this point asap.

Comment 19

[Adriano Santoni]

Attachment: English translation of our CPS for SSL Server and Code Signing certs

Comment 20

[Adriano Santoni]

Attachment: Last audit of our CA by our national supervising body

Comment 21

[Kathleen Wilson]

(In reply to comment #20)
> Created attachment 519599 [details]
> Last audit of our CA by our national supervising body

I see that the CNIPA website has changed. It appears that the current list of accredited national certification provides is now at the following urls. Correct?
http://www.digitpa.gov.it/certificatori_firma_digitale
http://www.digitpa.gov.it/principali-attivit%C3%A0/qcsp-english

From my notes:
"Audit Criteria used by CNIPA
http://www.cnipa.gov.it/site/_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. "

What is the current URL where I can find this document?

Comment 22

[Kathleen Wilson]

>> 2) Attach to this bug, in PDF form, the English version of the CPS for SSL 
>> and Code Signing Certs. I do not want to download Actalis' File Protector 
>> desktop application to read Actalis' CPS.
> 
> Find our CPS attached (I do not understand your reference to our desktop
> application).
> 

Oh, I see. When I download the current versions of the files from
http://portal.actalis.it/Info/cmsContent?cmsRef=actalis/Info/Manuali
I have to attach .pdf to the filename, and then I'm able to open it.

Comment 23

[Adriano Santoni]

(In reply to comment #21)
> (In reply to comment #20)
> > Created attachment 519599 [details]
> > Last audit of our CA by our national supervising body
> I see that the CNIPA website has changed. It appears that the current list of
> accredited national certification provides is now at the following urls.
> Correct?
> http://www.digitpa.gov.it/certificatori_firma_digitale
> http://www.digitpa.gov.it/principali-attivit%C3%A0/qcsp-english
> From my notes:
> "Audit Criteria used by CNIPA
> http://www.cnipa.gov.it/site/_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. "
> What is the current URL where I can find this document?

Here it is: http://www.digitpa.gov.it/sites/default/files/linee%20guida%20per%20la%20vigilanza%20sui%20certificatori%20qualificati%20v1.2.pdf

It is also referenced at http://www.digitpa.gov.it/firma-digitale/certificatori-accreditati

Comment 24

[Kathleen Wilson]

Thanks.  My only remaining question is about OCSP...

>> 3) My notes indicate that you had planned to release an OCSP service. Is it
>> available now?  If yes, please provide a url to a test website whose SSL cert
>> has the OCSP URI in the AIA.
> 
> I will check and reply to this point asap.

Comment 25

[Adriano Santoni]

(In reply to comment #24)
> Thanks.  My only remaining question is about OCSP...

Activation of an OCSP service for our SSL Server certificates is scheduled to be done by end of month. I will let you know as soon as it is active and will also provide the URL of a test web site whose SSL cert has the expected AIA.

Comment 26

[Kathleen Wilson]

I plan to start discussion for this request in early April. I will post a comment here in this bug when I start the discussion.

https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Comment 27

[Adriano Santoni]

(In reply to comment #24)

We have activated our OCSP service for SSL Server certs.

You can see a live example on this site: https://portal-pte.actalis.it

Comment 28

[Kathleen Wilson]

Thanks for the update. I've successfully browsed to the website with OCSP enforced in Firefox, and I verified that the OCSP URI in the AIA is set (to http://ocsp.actalis.it/AUTH-G1).

I hope that you are following the discussions in mozilla.dev.security.policy. In light of recent events it is likely that all CAs will be required to issue end-entity certs through intermediate CAs, and not directly from the root. 

I think we can still go ahead with the discussion of this request, but expect that there will be a resulting action item to update the hierarchy to use internally-operated intermediate CAs to sign end-entity certs.

I'll post an update in this bug when I start the discussion in a couple weeks.

Comment 29

[Kathleen Wilson]

I just now tried to browse to https://portal-pte.actalis.it several times, and each time I got the following error:

An error occurred during a connection to portal-pte.actalis.it.
The OCSP server experienced an internal error.
(Error code: sec_error_ocsp_server_error)

Comment 30

[Adriano Santoni]

(In reply to comment #29)
> I just now tried to browse to https://portal-pte.actalis.it several times,
> and each time I got the following error:

It was due to a temporary database problem; please try again and confirm the problem is solved.

Comment 31

[Kathleen Wilson]

It is working for me now.

What sort of monitoring do you have in place for OCSP? Had your monitoring already caught the problem before I reported it?

Comment 32

[Adriano Santoni]

(In reply to comment #31)
> It is working for me now.
> 
> What sort of monitoring do you have in place for OCSP? Had your monitoring
> already caught the problem before I reported it?

We currently have more than ten OCSP services in place and all the responders are constantly monitored by probes. The standard probe interval is 10 minutes.
Unfortunately, the probe for the Authentication CA you have tested was misconfigured and the problem wasn't reported correctly.
We have fixed the probe and we are confident the issue is solved.

Comment 33

[Kathleen Wilson]

OK. Thanks for the explanation.

I will start the discussion now.

Comment 34

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 35

[Kathleen Wilson]

I am now opening the first public discussion period for this request from Actalis to add the “Actalis Authentication CA G1” root certificate, and turn on the Websites and Code Signing trust bits.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “Actalis Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of Actalis must promptly respond directly in the discussion thread to all questions that are posted.

Comment 36

[Kathleen Wilson]

This request has been evaluated as per the Mozilla CA Certificate Policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request from Actalis to add the “Actalis Authentication CA G1” root certificate, and turn on the Websites and Code Signing trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Actalis, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. Actalis appears to provide a service relevant to Mozilla users: It 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.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main document of interest is the CPS for SSL and Code Signing Certs, which is provided in Italian and English.

CPS for SSL and Code Signing Certs: 
http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_certificati_SSL_server_e_Code_Signing_v2.0.4_IT.pdf http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_certificati_SSL_server_e_Code_Signing_v2.0.4_EN.pdf

Section 7 [Validation]. Actalis appears to meet the minimum requirements for subscriber verification, as follows:

* SSL: Actalis verifies the legal existence of the organization requesting the certificate, the identity of the certificate subscriber, and that the certificate subscriber has the exclusive right to use the domain name(s) to be listed in the certificate. This is documented in sections 3.2 and 3.3 of the CPS for SSL and Code Signing Certs.

* Email: Not Applicable. Actalis is not requesting the Email trust bit at this time.

* Code: Actalis verifies the legal existence of the organization requesting the certificate, and the identity and authority of the certificate subscriber. This is documented in sections 3.2 and 3.3 of the CPS for SSL and Code Signing Certs.

* EV Policy OID: Not requesting EV treatment.

Section 15 [Certificate Hierarchy]. 
* 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). There is an action item for Actalis to create a new CA hierarchy and begin migration to it (see below).

Other: 
* CRL: http://portal.actalis.it/Repository/AuthCA1/getCRL (Next Update: 30 hours)
** SSL CPS section 4.10.1: The CRL is regenerated and republished: at least every 6 hours

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

Section 8-10 [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. An audit statement was attached to this 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.

Based on this assessment I intend to approve this request from Actalis to add the “Actalis Authentication CA G1” root certificate, and turn on the Websites and Code Signing trust bits.

I will track the following action item in this 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.

Comment 37

[Kathleen Wilson]

Ooops!  Before I approve this request, I need to receive the audit statement for this year.  

Please update this bug provide a url to the updated audit statement when it is available.

Comment 38

[Rachid Innocenti]

Hello Everybody,
I am Rachid Innocenti from Actalis 

We have contacted our auditor DigitPA for the issuance of this year’s audit.
This year, DigitPA expects to start monitoring the certifiers only from September/October and therefore until then we will not receive the new audit.
We kindly ask if it is possible to begin the other steps of the root inclusion process so that we don’t get blocked, obviously binding the completion of our request to the issuance of the new audit as soon as we receive it.

We appreciate your collaboration.
Thank you

Comment 39

[Kathleen Wilson]

Does this mean that the future audits will always take place during the September/October time frame? Will the audits occur annually?

If the audit starts in September/October, when could you reasonably expect to have the audit completed and be able to post the audit statement?

Comment 40

[Rachid Innocenti]

Usually the audits are made every 18 months.
DigitPA answered us that they have not planned the supervision yet because they have some resources problems, but they estimate to start during the months of September/October, even if any date is certain yet. 

As this does not depend on us, we are not able to make an exact estimate about when they release to us the new audit.

We are hoping you can help us.

Comment 41

[Kathleen Wilson]

There is a discussion called "Frequency of Audits" in the mozilla.dev.security.policy forum.

The issue is that the current Mozilla CA Certificate Policy requires an updated audit annually.

Comment 42

[Kathleen Wilson]

(In reply to comment #41)
> There is a discussion called "Frequency of Audits" in the
> mozilla.dev.security.policy forum.
> 
> The issue is that the current Mozilla CA Certificate Policy requires an
> updated audit annually.

Based on the discussion so far, I do not think that there will be enough consensus to change the Mozilla CA Certificate Policy regarding annual audits.

Therefore, I think that Actalis will need to move to an annual audit cycle before I can approve this request.

Comment 43

[Rachid Innocenti]

The 18 month audit cycle is ordered by the Italian ministerial directives. 
It is the Italian State that has set out this term, therefore we cannot change it.

For your information, at the following address you can find the complete text of the law (in Italian)
http://archivio.cnipa.gov.it/HTML/RN_ICT_cron/07/2007_02_15_Circolare%20CNIPA%20n%2052.pdf

Here below is the translation of the relevant paragraph 

Paragraph 2 – Verifiche (audits)
Article 2.3

"Il periodo massimo di tempo che intercorre fra una verifica e quella successiva è stabilito in 
diciotto mesi."  

"The maximum period of time between one audit and another is eighteenth months." 

DigitPA has already exceeded the maximum time of 18 months from the last released audit

Comment 44

[David E. Ross]

Re comment #43:  

"The MAXIMUM [emphasis added] period of time between one audit and another is eighteenth months."  Please do not interpret the legally mandated maximum to also prohibit a shorter period.

Comment 45

[Rachid Innocenti]

The minimum period of time is not decided by us but by the Italian government, we have no authority to reduce in any way the period of time.

If the DigitPA (Italian public for the Digitization of Public Administration, therefore completely independent) were to decide to perform the audit every 36 months, we would have to submit to this request.

Comment 46

[David E. Ross]

Re comment #45:  

You seem to be saying that you would be penalized if you did better than what the law requires.  Is this correct?  

In any case, a law setting a MAXIMUM period between audits does not also set a MINIMUM period unless it explicitly states that additional restriction.

Comment 47

[Luciano Castro]

Hi David,


We are not saying it.
We are trying to explain that actually our Governement makes an audit every 36 months.
This is not something that we could change or speed up, because it is not on us.

Our next audit, from digitPA, will be on next months, as for every CA in Italy.

Our request and question is:
- Can you please help us in any way trying to solve all the other open points in the meantime? We would publish and give to our customers the SSL on Mozilla before the end of this year and we are really afraid that, in this way, we will take more time.
- We can't change the "schedule" time of digitPA. Is there something that we can do to prove your requirements?

Actalis belongs to Aruba Group, a solid, energic and fast-growing Italian Company. We really would continue working with Mozilla and helping in any way we can.
Please let me know what we can do (if there is anything) to speed up this phase.


Thanks.

Comment 48

[Kathleen Wilson]

(In reply to Luciano Castro from comment #47)
> We are trying to explain that actually our Governement makes an audit every
> 36 months.


Is your government changing the requirement to 36 months?

My current interpretation of the situation is that in order to be recognized as a government qualified CA, you have to be audited by DigitPA. Even though the current requirement appears to be that DigitPA audits the CA at least every 18 months, DigitPA currently does not have the resources to do so.

Mozilla's requirement is for an annual audit that meets the requirements of sections 9, 10, and 11 of http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html.

Is there a reason why Actalis cannot have an additional audit by a different auditor to meet the requirements of Mozilla's CA Certificate Policy? This additional audit would focus on the CPS and operations of SSL and Code Signing certs that are issued within the hierarchy of the "Actalis Authentication CA G1" root.

Comment 49

[Kathleen Wilson]

Before approving this request for inclusion, the following action items need to be completed by Actalis.

1) Update the audit cycle and related documentation to be annual (this is specific to SSL and code signing cert issuance, because those are the two trust bits being requested).

2) Complete the audit for this year.

Comment 50

[Adriano Santoni]

We have revised our CPS to clarify that we commit to an annual audit cycle, if necessary by engaging another auditor when DigitPA auditing schedule would not allow meeting such commitment.

Since we must wait a few more weeks to get our next audit, we also took the chance to migrate to a two-level PKI, with a Root CA and a Sub CA, where the former is only used to sing the Sub CA (and the related ARL), and is kept off-line, and the latter is used to issue EE certificates. Of course, we have also revised our CPS accordingly.

I wil shortly provide our new CPS, Root CA certificate and testing web site.

Comment 51

[Adriano Santoni]

We have published our new CPS at the following URL:
http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_certificati_SSL_server_e_Code_Signing_v2.1.0_EN.pdf

The IT translation will be done later on, after Mozilla approves the EN.
Our new Root CA is attached next to this comment.

A testing SSL Certificate is installed on the following web site:
https://portal-pte.actalis.it

Comment 52

[Adriano Santoni]

Attachment: New Actalis Root CA

I am attaching here our new Root CA. This one only issues certificates for our Sub CA, which is the CA actually signing end-entity certificate. See our new CPS for details.

Comment 53

[Kathleen Wilson]

(In reply to adriano.santoni from comment #51)
> We have published our new CPS at the following URL:
> http://portal.actalis.it/cms/actalis/Info/Manuali/
> CPS_certificati_SSL_server_e_Code_Signing_v2.1.0_EN.pdf
> 
> The IT translation will be done later on, after Mozilla approves the EN.
> Our new Root CA is attached next to this comment.
> 

I have reviewed the updated CPS, and I confirm that the concerns that were raised have been addressed (pending the new audit):

Section 1.3.1: The Root CA is used for issuing Sub CA certificates only and is kept off-line when not in use, whereas end-users certificates are issued by Sub CAs.
Within the framework of the service described in this document, both CA roles (Root CA and Sub CA) are played by Actalis S.p.A.

Section 8.1: The external audits performed DigitPA are carried out every 18 months as provided by Circolare CNI-PA n.52 of 2007. Actalis, however, commits to do what is necessary so that a conformity audit be done at least every 12 months, if necessary by engaging an external independent auditor so to enforce the annual periodicity.

Section 6.11: Multi-factor authentication is required for all CMS and WebRA/WebCA accounts capable of directly causing certificate issuance. … For performing most of the operations listed above the RA operator uses a specific type of account on the Certificate Management System. Such type of account requires strong two-factor authentication for logon. All security-relevant operations – e.g. authorization of certificate issuance – require the RA operator’s digital signature (smartcard-based) and are traced to the audit log.

Comment 54

[Kathleen Wilson]

(In reply to adriano.santoni from comment #52)
> Created attachment 563066 [details]
> New Actalis Root CA
> 
> I am attaching here our new Root CA. This one only issues certificates for
> our Sub CA, which is the CA actually signing end-entity certificate. See our
> new CPS for details.


I have imported the new root certificate into my FF browser, and have verified that I can browse to the test website, https://portal-pte.actalis.it/. I have also confirmed that I can import the corresponding CRL URLs.

Comment 55

[Kathleen Wilson]

Please confirm that you have performed the actions listed in #7 of https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

Comment 56

[Adriano Santoni]

Confirmed.

Comment 57

[Kathleen Wilson]

According to my notes, there is one remaining action item, which is to complete the current audit. Please update this bug when the audit statement is available.

Comment 58

[Adriano Santoni]

We have been audited by DigitPA on Jan 23 and 24. 
Find the audit report attached here.

Comment 59

[Adriano Santoni]

Attachment: DigitPA audit on Actalis 2012

Comment 60

[Eddy Nigg (StartCom)]

A few questions please....what is the audit criteria used for the audit and who has authorized this company to perform an audit and/or which qualifications does the auditor have?

Comment 61

[Adriano Santoni]

The criteria used for the audit are published at the following address:
http://www.digitpa.gov.it/firma-digitale/certificatori-accreditati
(see PDF document "Linee guida per la vigilanza sui certificatori qualificati")
They are based on ETSI TS 101 456
The auditor, DigitPA, is our national supervising body according to EU directive.
See here: http://ec.europa.eu/information_society/policy/esignature/eu_legislation/notification/italy/index_en.htm

Comment 62

[Eddy Nigg (StartCom)]

Thank you - I don't know enough Italian, I assume we need to get a translation of the audit report. Would that be possible? I can't easily copy the content from the letter in order to use some translation tool.

Comment 63

[Adriano Santoni]

This is my own translation of the essential parts:

Points of Excellence
====================
In the course of the audit we verified the availability and accuracy of many procedures. These appear to be clear and applicable even by subjects, with adequate preparation, who does not normally work in the CA services.

We found a lot of attention and care in the operating procedures and in the production and keeping of internal auditing records. The CA is thus encouraged to keep up such activities according to their audit plan.

We particularly appreciate the firewall architecture being used today, allowing to obtain an adequate security assurance that we suggest to keep up and updated.

Remarks
=======
The remarks reported in the previous supervision audit have been solved.

Conclusion
==========
The supervisory activity showed an adequate compliance to the regulations in force and a due attention to the handling of both day-by-day opeerations and exceptions.

Comment 64

[Adriano Santoni]

To complete the information provided, we hereby reply to the recent CA Communication (https://wiki.mozilla.org/CA:Communications#February_17.2C_2012):

1) Subordinate CAs within our PKI cannot be used for MITM or "traffic management" of domain names or IPs that the certificate holder does not legitimately own or control.

2) We do not issue subordinate CA certificate to any third party.

3) We have not issued any EV certificate that does not meet EV requirements.

4) Certificates chaining to our root CA cannot have the MD5 algorithm or RSA keys shorter than 1024 bits long.

5) We will update our operations and documentation as needed to meet the CA/Browser Forum baseline requirements by the effective date of July 1, 2012.

Comment 65

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 66

[Kathleen Wilson]

Please confirm that the attachment in Comment #65 is accurate and complete.

Comment 67

[Adriano Santoni]

We confirm that the attachment in Comment #65 is accurate and complete.

Comment 68

[Kathleen Wilson]

As per Comment #35, this request has been through public discussion, and the result was to move forward with this root inclusion request.

I have confirmed that Actalis has completed the action items that were identified and stated in Comment #49. I have also updated the attached Information Gathering document to reflect the new root certificate, updated CPS, and current audit statement. Therefore, I will proceed with recommending approval of this request.

This request has been evaluated as per the Mozilla CA Certificate Policy at

 http://www.mozilla.org/projects/security/certs/policy/

Here follows a summary of the assessment. If anyone sees any factual errors, please point them out.

To summarize, this assessment is for the request from Actalis to add the “Actalis Authentication Root CA” root certificate, and turn on the Websites and Code Signing trust bits.

Section 4 [Technical]. I am not aware of any technical issues with certificates issued by Actalis, or of instances where they have knowingly issued certificates for fraudulent use. If anyone knows of any such issues or instances, please note them in this bug report.

Section 6 [Relevancy and Policy]. Actalis appears to provide a service relevant to Mozilla users: It 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.

Policies are documented in the documents published on their website and listed in the entry on the pending applications list. The main document of interest is the CPS for SSL and Code Signing Certs, which is provided in Italian and English.

CPS for SSL and Code Signing Certs: 
http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_certificati_SSL_server_e_Code_Signing_v2.1.0_IT
http://portal.actalis.it/cms/actalis/Info/Manuali/CPS_certificati_SSL_server_e_Code_Signing_v2.1.0_EN.pdf


Section 7 [Validation]. Actalis appears to meet the minimum requirements for subscriber verification, as follows:

* SSL: Actalis verifies the legal existence of the organization requesting the certificate, the identity of the certificate subscriber, and that the certificate subscriber has the exclusive right to use the domain name(s) to be listed in the certificate. This is documented in sections 3.2 and 3.3 of the CPS for SSL and Code Signing Certs.

* Email: Not Applicable. Actalis is not requesting the Email trust bit at this time.

* Code: Actalis verifies the legal existence of the organization requesting the certificate, and the identity and authority of the certificate subscriber. This is documented in sections 3.2 and 3.3 of the CPS for SSL and Code Signing Certs.

* EV Policy OID: Not requesting EV treatment.

Section 15 [Certificate Hierarchy]. 
* According to CPS section 1.3.1, this root signs internally-operated subordinate CAs which sign end-entity certificates. It is kept off-line when not in use.

* CRL
http://portal.actalis.it/Repository/AUTH-ROOT/getLastCRL 
http://portal.actalis.it/Repository/AUTH-G2/getLastCRL (NextUpdate: 24 hours) 
CPS section 4.10.1: The CRL is re-generated and re-published at least every 24 hours

* OCSP: http://portal.actalis.it/VA/AUTH-G2

Section 8-10 [Audit]. 
* Audits are performed by DigitPA; the national supervising body according to EU directive. http://ec.europa.eu/information_society/policy/esignature/eu_legislation/notification/italy/index_en.htm
* Recent audit statement: https://bugzilla.mozilla.org/attachment.cgi?id=598788 
* Actalis is an accredited national certification service provider: http://www.digitpa.gov.it/firme-elettroniche/qcsp-english https://applicazioni.cnipa.gov.it/TSL/IT_TSL_HR.pdf
* Audit Criteria: 
http://www.digitpa.gov.it/firma-digitale/certificatori-accreditati 
(see PDF document "Linee guida per la vigilanza sui certificatori qualificati") http://www.digitpa.gov.it/sites/default/files/linee%20guida%20per%20la%20vigilanza%20sui%20certificatori%20qualific ati%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.
* CPS Section 8.1: The external audits performed DigitPA are carried out every 18 months as provided by Circolare CNI- PA n.52 of 2007. Actalis, however, commits to do what is necessary so that a conformity audit be done at least every 12 months, if necessary by engaging an external independent auditor so to enforce the annual periodicity.

Based on this assessment I intend to approve this request from Actalis to add the “Actalis Authentication Root CA” root certificate, and turn on the Websites and Code Signing trust bits.

Comment 69

[Kathleen Wilson]

To the representatives of Actalis: Thank you for your cooperation and your patience.

To all others who have commented on this bug or participated in the public
discussion: Thank you for volunteering your time to assist in reviewing this CA
request.

As per the summary in Comment #68, and on behalf of Mozilla I approve this request from Actalis to include the following root certificate in Mozilla:

* Actalis Authentication Root CA (websites, code signing)

I will file the NSS bug to effect the approved changes.

Comment 70

[Kathleen Wilson]

I have filed bug #742525 against NSS for the actual changes.