[cabfcert_policy] What is meant by "initial certificate issuance"?

Mon Jul 28 23:57:49 MST 2014

Ben, I don´t understand part (2). If the CA/RA has a prior relationship and have that information is because sometime in the past that customer went to the CA/RA and registered or apply for something, so we are again in part (1). And in any case, that information has a validity period to be used, so for example, if that info was collected 10 years ago, is not valid and have to do the registration process again.

I think "initial" is the first time, so option (a).

Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: Ben Wilson [mailto:Ben.Wilson at digicert.com] 
Enviado el: lunes, 28 de julio de 2014 18:42
Para: Barreira Iglesias, Iñigo; policyreview at cabforum.org
Asunto: RE: [cabfcert_policy] What is meant by "initial certificate issuance"?

I would like to bridge the gap in interpretation between (1) registration as required by policy (whether it be F2F in-person for individuals or completing all required steps for organizations) and (2) the concept that the RA/CA has a prior, pre-existing relationship with the applicant and has collected certain information in the past.  I'm wondering whether we say "initial .." is whatever is required when (a) there is a first encounter with the applicant or (b) the time period allowing for re-key has expired.  That handles (1) above.  Then, for (2) above, we say something that allows the CA/RA to pull information out of an existing account or record and still rely on it, associate it with the applicant, etc.  If we had (1) and (2) described, then when we talk about what "initial ..." is, we can say, "but for X, Y, or Z, the RA/CA can still rely on them as persistent records that do not need to be re-performed.

From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net] 
Sent: Monday, July 28, 2014 1:45 AM
To: Ben Wilson; policyreview at cabforum.org
Subject: RE: [cabfcert_policy] What is meant by "initial certificate issuance"?

Hi Ben,

In Europe the current directive allowed the countries to create its own law and regarding validation and validity of the data, in Spain for example, this period is for 5 years and during that time you can issue as many certificates as you want without requiring all the info again. Once these five years have ended then, if the same subscriber wants to request another (or the same) certificate has to again proof his identity in the RA and do it as the first time, for again, another period of 5 years. 

Besides, in the directive 93/1999 and in the recently approved regulation 2014, there´s an article about data protection for where and how collect all that info needed for the generation of certificates.

For example, in Izenpe we issue qualified certificates with a duration of 4 years, for the first renewal they don´t need to provide all the info or to proof again their identity, they can ask the renewal using other methods (for example signing the request form with the current certificate that is about to expire) and then, having a new one for other 4 years. For the second renewal, then you have to go to the RA and make a F2F identity validation and provide all the info as for the first time.

So, for your questions:

-          Initial registration is not the same that the initial certificate issuance but most of the time is the same date. But, you can make the initial registration and validation of the information and then, issue the certificate some days later. Some countries have a so called grace period for the issuance and the duration of the information gathered regarding identity proofing

-          Initial identity validation can be considered the same that initial registration because when you´re validating the information of the subscriber at the same time you´re registering that information, but well, can have another definition for them. For proofing I think is the same than validation.

In the ETSI documents this is solved using different services for these tasks. 

This is copied for you to check.

4.3        Certification services

The service of issuing certificates is broken down in the present document into the following component services for the purposes of classifying requirements:

·            Registration service: verifies the identity and, if applicable, any specific attributes of a subject. The results of this service are passed to the certificate generation service.

IB à this is where you identify the subscriber. This could be the initial registration and the initial  identity validation (as said these 2 can be the same)

NOTE 1:         This service includes proof of possession of non-CA generated subject private keys.

·            Certificate generation service: creates and signs certificates based on the identity and other attributes verified by the registration service.

IB à This is the initial certificate issuance. Again, usually is the same date but depending on your generation/issuance methods it can be delayed

·            Dissemination service: disseminates certificates to subjects, and if the subject consents, makes them available to relying parties. This service also makes available the TSP's terms and conditions, and any published policy and practice information, to subscribers and relying parties.

IB à this is when the certificate is delivery to the subject. If it´s an online process it can be at the same day, but again, can be different.

·            Revocation management service: processes requests and reports relating to revocation to determine the necessary action to be taken. The results of this service are distributed through the revocation status service.

·            Revocation status service: provides certificate revocation status information to relying parties. This may be based upon certificate revocation lists or an online service which provides status information on an individual basis. The status information may be updated on a regular basis and hence may not reflect the current status of the certificate.

And optionally:

·            Subject device provision service: prepares, and provides or makes available signature-creation devices, or other secure user device, to subjects.

NOTE 2:   Examples of this service are:

i)        a service which generates the subject's key pair and distributes the private key to the subject;

ii)       a service which prepares the subject's signature-creation module and enabling codes and distributes the module to the registered subject.

This subdivision of services is only for the purposes of clarification of policy requirements and places no restrictions on any subdivision of an implementation of the CA services.

Also in 7.3.1 you can read "Verification of the subject's identity shall be at time of registration by appropriate means and in accordance with national law".

Here, included some definitions and where used in the current regulation. 

Article 3
Definitions

'person identification data' means a set of data enabling to establish the identity of natural or legal person, or natural person representing a legal person;

Article 24
Requirements for qualified trust service providers

1.               When issuing a qualified certificate for a trust service, a qualified trust service provider shall verify, by appropriate means and in accordance with national law, the identity and, if applicable, any specific attributes of the natural or legal person to whom a qualified certificate is issued.

Regards

Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net

945067705

ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna. KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por error le agradeceriamos que no hiciera uso de la informacion y que se pusiese en contacto con el remitente.

De: policyreview-bounces at cabforum.org [mailto:policyreview-bounces at cabforum.org] En nombre de Ben Wilson
Enviado el: jueves, 24 de julio de 2014 22:36
Para: policyreview at cabforum.org
Asunto: [cabfcert_policy] What is meant by "initial certificate issuance"?

The NISTIR document (and other PKI documents) refer to steps taken as part of "initial certificate issuance" and contrast those with steps taken during "certificate renewal".  This comes up first in section 3.2.3.1 of the NISTIR 7924.  

There are lifecycle states such as re-key, re-issue, etc., which we have debated but have not fully defined.   If we recommend that "initial certificate issuance" be defined by NISTIR 7924, what is the definition?  "Initial registration" is also used.  What does that mean, or how is that different from the former?

These terms are used in sections 3.2.3.1, 3.3.1, 3.3.2, 4.6.3, 4.7.3, and 4.8.1,  and Section 3.2 of RFC 3647 is titled "Initial Identity Validation".   "Initial identity proofing" is also mentioned in section 4.8.3.

This question is also related to draft ballot 123 dealing with re-validation of information because in section 11.13 of the EVG we talk about "existing subscribers" and "the age of validated data ... before revalidation is required."

Several CABF documents make a distinction between initial proofing and information that is subsequently used for renewal.  I think we need to improve our understanding of these things.

Thoughts?  Are there any broadly accepted industry definitions we could use?

Meanwhile, I'll also take a look to see what I can find.

Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/policyreview/attachments/20140729/9d8ff67c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 19121 bytes
Desc: image001.png
Url : https://cabforum.org/pipermail/policyreview/attachments/20140729/9d8ff67c/attachment-0001.png 