Certum Root Inclusion Request
Kathleen Wilson
certificate and enable all three trust bits. The request is to also
enable EV.
Certum (Broader Certification Center) is an organizational unit of
Unizeto Technologies SA, providing certification services related to
electronic signatures. It is the oldest public certification authority
in Poland and a commercial certification authority, operating on a
global scale - serving customers in over 50 countries worldwide.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=532377
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Certum
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=471560
Noteworthy points:
* Certum currently has a root named “Certum CA” included in NSS.
Eventually, the certificates under the old “Certum CA” root will be
moved to this new root. (starting with SSL certs).
* Currently this new root has two sub-CAs:
** Certum Level I CA -- Signs certs for testing. DV only. Domain
ownership verified via email exchange.
** Certum Extended Validation CA – Signs EV SSL certs
* Eventually the new root will also have the following sub-CAs:
** Certum Level II CA -- Signs certs for S/MIME, not for SSL or code
signing.
** Certum Level III CA -- Signs certs for SSL , code signing, and S/MIME
** Certum Level IV CA – Signs certs for certification authorities,
non-repudiation authorities and global network-based electronic
transaction systems.
** Certum Partners CA. Signs certs for external CAs.
*** Comment from Certum: We do plan to use this root for subordinate CAs
that are operated by external third parties, special intermediate
certificate will be created and proper changes to CPS will be done when
needed.
* The CP and CPS documents are in English.
* The request is to enable all three trust bits.
** Organizational verification is performed for Levels III, IV, and EV.
** Section 3.2 of the CPS describes the procedures for authenticating
the identity of the certificate subscriber and verifying the existence
and identity of the organization.
** CPS section 3.2.2: A registration authority is committed to verify
the correctness and truthfulness of all data provided in an application.
** CPS section 3.2.2: In the case of email certificates, registration
authority verifies an email address. The aim of this action is to
receive by the subscriber an authentication data sent to the address
which has previous placed in the certification request.
** CPS section 3.2.2: In the case of certificates issued for devices,
authentication may be accomplished by verifying access to the domain
placed in the certificate request. CERTUM may verify the subscriber’s
right to use the domain name and email address by using one of the
following methods:
*** domain verification – when a verification element indicated by
CERTUM is placed on destination server
*** email address verification – when the Subscriber is required to be
able to answer an e-mail sent by CERTUM to his/her/its address.
** CPS section 3.2.2: registration authority operator may – in doubtful
cases – verify the registration of the domain in publicly available
WHOIS services.
** CPS section 4.2.2.3: Certificate issuance denial can occur: … the
subscriber cannot prove his/her rights to proposed DN,
** CPS section 3.2.2: Registration authority may collect the data
required for identification by its own, e.g. through publicly available
databases. Authentication of legal entity’s identity has two purposes.
The first purpose is to prove that at the time of application
examination the legal entity stated in the application existed; the
second purpose is to prove that a private entity applying for a
certificate or receiving it is authorized by this legal entity to
represent it. Submitted documents (or collected data) should prove:
*** identity of the subscriber or certificate administrator (in the case
of certificates issued for legal entities or devices),
*** existence of the legal entity or institution,
*** the right of the subscriber or the certificate administrator to act
on behalf of the institution or legal entity.
*** registration authority operator may – in doubtful cases – verify the
registration of the domain in publicly available WHOIS services.
** There are two basic ways of legal entity’s identity authentication.
The first one requires the legal entity’s authorized representative’s
personal attendance in a registration authority, or a registration
authority representative’s presence in person in the legal entity’s seat
(specified in the application). In the second case, the identity can be
authenticated on-line by means of messages exchanged directly with a
certification authority or its agent.
** CPS table 6.6 on page 82. Maximum usage periods of subscriber certs.
*** Level I: 3 months (DV)
*** Level II: 1 year (not SSL)
*** Level III: 2 years (OV)
*** Level IV: 2 years
*** EV SSL: 27 months
* EV Policy OID: 1.2.616.1.113527.2.5.1.1
** In the EV CPS sections 14 and 15 describe verification of the
applicant’s legal existence and identity. Section 16 describes
verification of the applicant’s physical existence. Section 17 describes
verification of the applicant’s operational existence. Section 18
describes verification of the applicant’s domain name.
* Test Website: https://juice.certum.pl/
*CRL:
** ARL: http://crl.certum.pl/ctnca.crl
** Class 1 CRL: http://crl.certum.pl/c1.crl (Next Update: 1 month)
** EV SSL CRL: http://crl.certum.pl/evca.crl (Next Update: 9 days)
** All Certum CRLs:
http://www.certum.eu/certum/cert,certificates_crl_lists.xml
** EV CPS: CRLs are updated and reissued at least every seven days, and
the nextUpdate field value SHALL NOT be more ten days; (end-entity certs)
* OCSP:
* Certum plans to make OCSP available in January 2011.
** EV CPS: Since January 2011 Certum Extended Validation CA will
provide revocation information via an Online Certificate Status Protocol
(OCSP) service and update that service at least every four days. OCSP
responses from this service will have a maximum expiration time of ten
days. (end-entity certs)
* Audit: Ernst & Young performs the audits according to the WebTrust CA
and WebTrust EV criteria, and the audit reports are posted on the
webtrust.org website at
https://cert.webtrust.org/SealFile?seal=1072&file=pdf (2010.04.14)
https://cert.webtrust.org/ViewSeal?id=980 (2009.10.20)
Potentially Problematic Practices:
* Issuing SSL Certificates for Internal Domain: “We validate
organization, and person responsible for certification process”
This begins the discussion of the request from Certum to add the “Certum
Trusted Network CA” root certificate, enable all three trust bits, and
enable EV. 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
Gervase Markham
> Certum has applied to add the “Certum Trusted Network CA” root
> certificate and enable all three trust bits. The request is to also
> enable EV.
I have reviewed this request and have only one comment.
> *** email address verification – when the Subscriber is required to be
> able to answer an e-mail sent by CERTUM to his/her/its address.
How does Certum determine the email address to send the email to? Do
they have a limited set of local names @ the domain they permit? If so,
what is that list?
Gerv
Michał Proszkiewicz
For SSL certificates it is one of the followig addresses:
ad...@yourdomain.com
admini...@yourdomain.com
webm...@yourdomain.com
ssla...@yourdomain.com
ro...@yourdomain.com
hostm...@yourdomain.com
postm...@yourdomain.com
One can choose this address during certificate purchase procedure.
For email certificates, at the moment, we allow only one email address
in DN and SAN (same address put in two places), and this is the address
that we verify.
Regards,
Michal Proszkiewicz
David E. Ross
I request that this list be pruned to comply with the pending revisions
the Mozilla's policy by removing ssla...@yourdomain.com and
ro...@yourdomain.com.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Michał Proszkiewicz
We are going to make that change, but keep in mind that it will take
some time. I hope that this issue won't hold our root inclusion up.
Regards,
Michal Proszkiewicz
Kathleen Wilson
> Certum has applied to add the “Certum Trusted Network CA” root
> certificate and enable all three trust bits. The request is to also
> enable EV.
Thank you to those of you who have contributed to this discussion about
Certum’s root inclusion request.
So far there is one action item, which I plan to track separately in the
bug.
ACTION Certum: Remove ssla...@yourdomain.com and ro...@yourdomain.com
from the list of addresses that may be used for SSL certificate
verification.
Does anyone else plan to review and comment on this root inclusion
request in this discussion?
Thanks,
Kathleen
Eddy Nigg
>
> ACTION Certum: Remove ssla...@yourdomain.com and ro...@yourdomain.com
> from the list of addresses that may be used for SSL certificate
> verification.
>
> Does anyone else plan to review and comment on this root inclusion
> request in this discussion?
Not at the moment, it would be great if some others could step in. As
such I haven't seen anything of particular concern except what Gerv
already mentioned and that at this stage and time we ought to see an
operating OCSP responder. This item has to be completed IMO before
approval (due to past experience).
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Kathleen Wilson
Thanks again to those of you who reviewed and commented on this request.
This discussion resulted in the following two action items.
1) ACTION Certum: Remove ssla...@yourdomain.com and ro...@yourdomain.com
from the list of addresses that may be used for SSL certificate
verification.
2) ACTION Certum: Provide OCSP service and test with Firefox browser.
There are two levels to this action item. First, there is the OCSP
responder for end-entity certs which may be tested as described here:
https://wiki.mozilla.org/CA:Recommended_Practices#OCSP.
Second, since this request is for EV, further testing will need to be
done as described here:
https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version
These two action items will be tracked in the bug.
https://bugzilla.mozilla.org/show_bug.cgi?id=532377
After I have confirmed that the action items have been satisfactorily
completed, I plan to recommend approval of Certum's request to add the
“Certum Trusted Network CA” root certificate, enable all three trust
bits, and enable EV.
All follow-up on this request should be posted directly in the bug.
Thanks,
Kathleen