Keynectis EV Enablement Request
Kathleen Wilson
public) has request EV Enablement of the Certplus �Class 2 Primary CA�
root certificate. Note: Keynectis was created by merging two previous
French certification operators, Certplus and PK7.
The request is documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=497917
And in the pending certificates list here:
http://www.mozilla.org/projects/security/certs/pending/#Keynectis
Summary of Information Gathered and Verified:
https://bugzilla.mozilla.org/attachment.cgi?id=426594
Noteworthy points:
* This root is already included in NSS. Inclusion was approved in the
following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=335392#c29
* This root has two internally-operated subordinate CAs:
** 1) Class 2 KEYNECTIS CA, issues SSL certificates
** 2) KEYNECTIS Extended Validation CA, issues EV SSL certificates.
* The CP and CPS documents are in English and French.
** EV SSL CPS (English):
https://bugzilla.mozilla.org/attachment.cgi?id=387860
** CPS (French):
http://www.keynectis.com/PC/CPS_KEYNECTIS_120407v1.1.pdf
** SSL CPS (French):
https://www.keynectis.com/static/content/common/pc-dpc/DSQ_PC_PC_AC_KEYNECTIS_SSL_1.2s.pdf
* The websites and email trust bits are currently enabled for this root.
** Email: Keynectis verifies that the entity submitting the request
controls the email account associated with the email address referenced
in the certificate. (CPS section 2.3)
** SSL: Keynectis verifies domain control by communicating with the
Administrative Contact listed in WHOIS. (CPS section 6.1.3)
* The current request is to enable EV for this root.
* EV Policy OID: 1.3.6.1.4.1.22234.2.5.2.3.1
* EV SSL CPS section 3.2.2.4: For the purpose of EV certificate
delivery, the verification also requires to check that the domain name
featured in the request belongs to the Applicant, which is therefore
entitled to use it. In this way, verifications are made against domain
name database in order to verify Applicant is a registered holder, or
has exclusive control, of the domain name to be included in the EV
Certificate. Checks on domain names are such that the KEYNECTIS EV CA
confirms such domain name satisfies the following requirements:
** The domain name is registered with an Internet Corporation for
Assigned Names and Numbers (ICANN) approved registrar or a registry
listed by the Internet Assigned Numbers Authority (IANA);
** Domain registration information in the WHOIS is public and shows the
name, physical address, and administrative contact information for the
organization. For Government Entity Applicants, the CA relies on the
domain name listed for that entity in the records of the QGIS in
Applicant�s Jurisdiction to verify Domain Name.
** Applicant: is the registered holder of the domain name; or has been
granted the exclusive right to use the domain name by the registered
holder of the domain name;
** Applicant is aware of its registration or exclusive control of the
domain name.
** In case an EV Certificate request is made for a domain name
containing mixed character KEYNECTIS EV CA visually compares the domain
name with mixed character sets with known high risk domains. If a
similarity is found then the EV Certificate Request is flagged as High
Risk. The CA performs appropriate additional authentication and
verification to be certain that Applicant and the target in question are
the same organization.
* Test Website: https://www.keynectis.com
* CRL:
** Root CA CRL: http://www.certplus.com/CRL/class2.crl
** EV certificates CRL:
http://trustcenter-crl.certificat2.com/keynectis/class2keynectisevca.crl
** NextUpdate: 7 days
** EV SSL CPS section 2.3: CRLs are published at least every 24 (twenty
four) hours.
* OCSP: http://kvalid.keynectis.com/evssl-ocsp/
** The OCSP service is updated every hour, and OCSP responses have an
expiration date/time equal to that of the CRL (thus, max 7 days for the
"Keynectis EV CA")
* Other: Keynectis delegates domain validation to third parties; see EV
SSL CPS section 1.3.8.
* Audit: The WebTrust EV Readiness audit was performed by KPMG. The
audit report and management assertion was attached to the bug:
https://bugzilla.mozilla.org/attachment.cgi?id=382979. I exchanged email
with an auditor at KPMG who confirmed the authenticity of the document.
Keynectis has also been audited according to the ETSI 101 456 criteria
by La S�curit� des Technologies de l'Information (LSTI), and the audit
is valid until October 2011.
This begins a one-week discussion period. After that week, 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
David E. Ross
> Keynectis (a French commercial CA issuing certificates to the general
>
> This begins a one-week discussion period. After that week, 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
CN = Class 2 Primary CA
O = Certplus (not the current owner)
Is this another case of unclear identification (similar to SwissBIT)?
--
David E. Ross
<http://www.rossde.com/>.
Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation. © 1997
Eddy Nigg
> French certification operators, Certplus and PK7.
>
Before even starting reviewing some of the information of this request
I'm curious to know if and how previous roots affect this request. Are
there CA roots from any of the previous operators? What is the relation
to those roots (if any)?
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Erwann Abalea
> On 3/10/10 12:41 PM, Kathleen Wilson wrote:
>> Keynectis (a French commercial CA issuing certificates to the general
>> public) has request EV Enablement of the Certplus “Class 2 Primary CA”
>> root certificate. Note: Keynectis was created by merging two previous
>> French certification operators, Certplus and PK7.
[...]
> CN = Class 2 Primary CA
> O = Certplus (not the current owner)
>
> Is this another case of unclear identification (similar to SwissBIT)?
This Root CA was created before the merge of Certplus and PK7. Now, Certplus
exists both as a company 100% held by Keynectis, and as a brand (and since we
own the company, we also own the brand).
If you go to "http://bases-marques.inpi.fr/Typo3_INPI_Marques/", and search for
the brand "Certplus", you'll find the evolution of the brand "Certplus", and the
transmission of this brand (first to a company named "Infrasec", which was the
first name of the merge Certplus+PK7, which was renamed "Keynectis").
INPI (National Institute of Industrial Property) is the french legal entity
responsible for centralization of industrial property (brands, patents, ...).
So Certplus is really owned by Keynectis, just like Thawte is owned by VeriSign.
--
Erwann
Erwann Abalea
>> Keynectis (a French commercial CA issuing certificates to the general
>> public) has request EV Enablement of the Certplus “Class 2 Primary CA”
>> root certificate. Note: Keynectis was created by merging two previous
>> French certification operators, Certplus and PK7.
>>
>
> Before even starting reviewing some of the information of this request
> I'm curious to know if and how previous roots affect this request. Are
> there CA roots from any of the previous operators? What is the relation
> to those roots (if any)?
PK7 didn't have a root included in Mozilla products.
Certplus had one, this one, in fact. And as I replied to David Ross, Keynectis
owns all Certplus material, including this root. We are just extending its usage
to EVSSL.
--
Erwann
Franck Leroy
> Eddy Nigg a écrit :
>
> >> Keynectis (a French commercial CA issuing certificates to the general
> >> public) has request EV Enablement of the Certplus “Class 2 Primary CA”
> >> root certificate. Note: Keynectis was created by merging two previous
> >> French certification operators, Certplus and PK7.
>
Hello erwann
Why did you keep O=Certplus (instead of Keynectis) in the sub-CA as it
has be created un July 2009 ?
Franck
eab...@gmail.com
Strange, this message still hasn't synchronized with the m.d.s.policy
newsgroup. I'm replying here.
The brand Certplus gained some popularity in France, when we were a
VeriSign affiliate (1998 to 2004, approximately), and we wanted to
keep the benefit of previous work. That's why we kept is when creating
the sub-CA used to produce EV certificates.
And in order to facilitate the move to KEYNECTIS, we also introduce an
"OU=Entity of KEYNECTIS for CA services" field, and also a
"CN=KEYNECTIS Extended Validation CA".
--
Erwann
chemalogo
> > Why did you keep O=Certplus (instead ofKeynectis) in the sub-CA as it
> > has be created un July 2009 ?
From my point of view "O" should be KEYNECTIS who is the real name of
the company, and the brand could be placed in CN.
The usage of OU to inform that Certplus is an "Entity of KEYNECTIS for
CA services" does not follow the underlying philosophy of this field,
that is, to state an Organizational Unit.
I also miss, probably in the O field the VAT number, or registration
number that made easier to uniquely identify the company behind and to
bind more closely the company with the certificate.
As I see it there is a lack of information in the certificate to bind
the legal person behind with the certificate itself and
responsibilities that might arise from misuse.
On Mar 11, 9:31 pm, Franck Leroy <fr.le...@gmail.com> wrote:
> On 11 mar, 15:46, Erwann Abalea <erwann.aba...@keynectis.com> wrote:
>
> > Eddy Nigg a écrit :
>
> > >>Keynectis(a French commercial CA issuing certificates to the general
> > >> public) has request EV Enablement of the Certplus “Class 2 Primary CA”
> > >> root certificate. Note:Keynectiswas created by merging two previous
> > >> French certification operators, Certplus and PK7.
>
> Hello erwann
>
> Why did you keep O=Certplus (instead ofKeynectis) in the sub-CA as it
Ben Wilson
This request is just to EV-enable the root. The root was created in 1999
and has already been included since 2007. The only issue that this
discussion should address is EV enablement. If a useful root has been
transferred by assignment to other companies, it cannot be changed because
then you would have a new root. It's a fact of modern business that
companies merge and sometimes their names change. The way to handle this is
not to look to the contents of the root, but to look to the contents of the
certificates that the root issues. If those certificates instruct the
relying party where to find the relevant information, then that should
suffice. Section 7 of the KEYNECTIS EV SSL CPS clearly indicates that
recipients of such certificates will be able to obtain the necessary
information, and the KPMG Audit Report based on the WebTrust for CAs -
Extended Validation Audit Criteria confirms this. So I would suggest that
this request be approved to move forward.
Ben Wilson
DigiCert, Inc.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Moudrick M. Dadashov
>
> I also miss, probably in the O field the VAT number, or registration
> number that made easier to uniquely identify the company behind and to
> bind more closely the company with the certificate.
Do you know any good syntax how to present things like VAT and
registration numbers in the certificate?
M.D.
cell: +370-699-26662
Eddy Nigg
> Do you know any good syntax how to present things like VAT and
> registration numbers in the certificate?
>
It's called id-at-serialNumber OID 2.5.4.5 perhaps?
Erwann Abalea
> On 03/17/2010 07:31 PM, Moudrick M. Dadashov:
>> Do you know any good syntax how to present things like VAT and
>> registration numbers in the certificate?
>
> It's called id-at-serialNumber OID 2.5.4.5 perhaps?
That replies to the "where" question, not the "how" one :)
And in fact, we do that for EV certificates, since it's mandatory (see
CA/Borwser Forum's Guidelines).
The audit delivered by KPMG states that our practices are compliant with
Webtrust for CA - EV Audit Criteria.
--
Erwann
Moudrick M. Dadashov
> Eddy Nigg a écrit :
>> On 03/17/2010 07:31 PM, Moudrick M. Dadashov:
>>> Do you know any good syntax how to present things like VAT and
>>> registration numbers in the certificate?
>> It's called id-at-serialNumber OID 2.5.4.5 perhaps?
>
> That replies to the "where" question, not the "how" one :)
>
> And in fact, we do that for EV certificates, since it's mandatory (see
> CA/Borwser Forum's Guidelines).
Sorry, in fact I was asking "where" :)
But I'm still not sure if that OID is the best place for this sort of info.
M.D.
cell: +370-699-26662
Eddy Nigg
I don't think anything more intelligent exists, maybe you want to
propose a new OID to the ITU?
Erwann Abalea
> On 03/18/2010 12:34 PM, Moudrick M. Dadashov:
>> Erwann Abalea wrote:
>>
>>> Eddy Nigg a écrit :
>>>
>>>> On 03/17/2010 07:31 PM, Moudrick M. Dadashov:
>>>>
>>>>> Do you know any good syntax how to present things like VAT and
>>>>> registration numbers in the certificate?
>>>>>
>>>> It's called id-at-serialNumber OID 2.5.4.5 perhaps?
>>>>
>>> That replies to the "where" question, not the "how" one :)
>>>
>>> And in fact, we do that for EV certificates, since it's mandatory (see
>>> CA/Borwser Forum's Guidelines).
>>>
>> Sorry, in fact I was asking "where" :)
>>
>> But I'm still not sure if that OID is the best place for this sort of
>> info.
>
> I don't think anything more intelligent exists, maybe you want to
> propose a new OID to the ITU?
Are we still talking about EV certificates? If yes, then one should keep in mind
the guidelines given by the cabforum (www.cabforum.org/Guidelines_v1_2.pdf). See
page 20:
-----
Registration Number
Certificate field: Subject:serialNumber (OID: 2.5.4.5)
Required/Optional: Required
Contents: For Private Organizations, this field MUST contain the Registration
(or similar) Number assigned to
the Subject by the Incorporating or Registration Agency in its Jurisdiction of
Incorporation or Registration, as
appropriate. If the Jurisdiction of Incorporation or Registration does not
provide a Registration Number, then the
date of Incorporation or Registration SHALL be entered into this field in any
one of the common date formats.
For Government Entities that do not have a Registration Number or readily
verifiable date of creation, the CA
SHALL enter appropriate language to indicate that the Subject is a Government
Entity.
For Business Entities, the Registration Number that was received by the Business
Entity upon government
registration SHALL be entered in this field. For those Business Entities that
register with an Incorporating Agency
or Registration Agency in a jurisdiction that does not issue numbers pursuant to
government registration, the date
of the registration SHALL be entered into this field in any one of the common
date formats.
-----
That's for end-user certificates, of course. For an Root CA or a subordinate CA,
nothing is required in the naming.
So yes, this OID is the best place to put a registration number, for an EV
certificate :)
Is this thread the place for this discussion?
--
Erwann
Moudrick M. Dadashov
> On 03/18/2010 12:34 PM, Moudrick M. Dadashov:
>> Erwann Abalea wrote:
>>
>>> Eddy Nigg a écrit :
>>>
>>>> On 03/17/2010 07:31 PM, Moudrick M. Dadashov:
>>>>
>>>>> Do you know any good syntax how to present things like VAT and
>>>>> registration numbers in the certificate?
>>>>>
>>>> It's called id-at-serialNumber OID 2.5.4.5 perhaps?
>>>>
>>> That replies to the "where" question, not the "how" one :)
>>>
>>> And in fact, we do that for EV certificates, since it's mandatory (see
>>> CA/Borwser Forum's Guidelines).
>>>
>> Sorry, in fact I was asking "where" :)
>>
>> But I'm still not sure if that OID is the best place for this sort of
>> info.
>>
>
> I don't think anything more intelligent exists, maybe you want to
> propose a new OID to the ITU?
>
Permanent Identifiers:
The permanent identifier is an optional feature that may be used by a
CA to indicate that two or more certificates relate to the same
entity, even if they contain different subject name (DNs) or
different names in the subjectAltName extension, or if the name or
the affiliation of that entity stored in the subject or another name
form in the subjectAltName extension has changed.
I like it because along with subject's ID (VAT or any other reg #) it
allows to indicate the source of the ID (assigner):
id-on-permanentIdentifier OBJECT IDENTIFIER ::= { id-on 3 }
PermanentIdentifier ::= SEQUENCE {
identifierValue UTF8String OPTIONAL,
-- if absent, use a serialNumber attribute,
-- if there is such an attribute present
-- in the subject DN
assigner OBJECT IDENTIFIER OPTIONAL
-- if absent, the assigner is
-- the certificate issuer
In tis sense it looks more attractive.
M.D.
cell: +370-699-26662
Kathleen Wilson
Kathleen Wilson
Kathleen Wilson
> root certificate. Note: Keynectis was created by merging two previous
> French certification operators, Certplus and PK7.
>
> The request is documented in the following bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=497917
>
> And in the pending certificates list here:
> http://www.mozilla.org/projects/security/certs/pending/#Keynectis
>
> Summary of Information Gathered and Verified:
> https://bugzilla.mozilla.org/attachment.cgi?id=426594
>
> Noteworthy points:
>
> * This root is already included in NSS. Inclusion was approved in the
> following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=335392#c29
All,
Let’s please return this discussion to the topic of the request to EV
enable the Certplus “Class 2 Primary CA” root certificate.
To summarize the discussion so far…
1) Issuer values
There were questions raised about the clarity of the issuer information:
CN = Class 2 Primary CA
O = Certplus
C = FR
Certplus is now part of Keynectis, due to a merge. It is common
practice for root certs to be transitioned to a new owner during a merge
or acquisition. It is also common practice for CAs to maintain
well-known brand names.
ACTION: None
2) Other roots involved in the merge
There was a question about what other roots are included in NSS from
Certplus and PK7.
This Certplus “Class 2 Primary CA” is the only root included in NSS that
is owned by Keynectis.
ACTION: None
3) O=Certplus in sub-CA
There was a question about why the O in the sub-CA is Certplus.
The Certplus brand is owned by Keynectis. That information is publicly
available and easily found via an internet search.
ACTION: None
4) Info binding root to legal identity
There was a concern raised that the information in the cert doesn’t seem
to bind the legal person behind the cert to the company owning the cert.
The root cert was created in 1999 when the name of the organization was
Certplus. See #1 above.
ACTION: None
5) VAT and Registration numbers
Please see the new discussion called “VAT and Registration Numbers in
Root Certs” if you are interested in following up on it.
ACTION: None
My assessment is that nothing in this discussion has raised a concern
that should prevent EV from being enabled for this Certplus “Class 2
Primary CA” root certificate.
It is my opinion that this discussion may be closed and that I should
proceed with recommending approval in the bug.
Kathleen
Kathleen Wilson
comments and feedback to this discussion. Your contributions are
greatly appreciated.
This discussion was in regards to the request from Keynectis to enable
EV in the Certplus “Class 2 Primary CA” root certificate.
There are no open action items resulting from this discussion.
I will post a summary of this request and my recommendation for approval
in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=497917
I am now closing this discussion. Any further follow-up on this request
should be added directly to the bug.
Thanks,
Kathleen