(sent from home, this will not go to public, unless you forward it)
It depends.
If the QCStatement extension declares the
id-etsi-qcs-SemanticsId-Natural semantics identifier, then yes, the
serialNumber will contain the passport number, IDcard number, or
other (there's a list in EN 319412-1). The data contained in this
attribute is structured. For example, for me, this serialNumber will
be "PASFR-07CL42154" if I present my french passport. This
information is not sensitive.
If there's no semantics identifier declared in the QCStatements
extension, or if this extension is missing, the serialNumber is
local to the CA. And of course, a relying party would have to ask
the CA to point to the right "Robert Smith" individual.
That doesn't fit well with web server certificates... Even if the
serialNumber contains a global identifier (such as passport), the
probability that as a user I can compare the passport number found
in the certificate to the real passport number of Robert Smith is
hardly higher than zero.
2016-08-29 20:36 GMT+02:00 Kirk Hall <[email protected]
<mailto:[email protected]>>:
Erwann, you mention the serialNumber attribute for a natural
person – I assume this is not a Social Security number or other
sensitive information?
But if each CA assigns its own serialNumber for the same (or
different) “Robert Smith,” I don’t see how a user can figure out
which Robert Smith it is dealing with…
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of *Erwann Abalea
*Sent:* Friday, August 26, 2016 1:47 AM
*To:* Moudrick M. Dadashov <[email protected] <mailto:[email protected]>>
*Cc:* [email protected] <mailto:[email protected]>
*Subject:* Re: [cabfpub] givenName and surname revived
That’s easily done for a certificate issued to a legal person if
you really need it:
- EN 319412-4 asks you to follow CABF BR or EVG, which don’t
prevent you from adding other attributes or extensions
- add the organizationIdentifier attribute formatted as
described in EN 319412-1 section 5.1.4
- add a QCStatements extension containing the qcStatement-2
QC-STATEMENT (as defined in RFC3739), and populate the
semanticsIdentifier element with the
id-etsi-qcs-SemanticsId-Legal OID
Same goes for a certificate issued to a natural person, just use
the serialNumber attribute instead of the
organizationIdentifier, fill it according to EN 319412-1 section
5.1.3, use id-etsi-qcs-SemanticsId-Natural OID as the semantics
identifier.
Of course, you’re not REQUIRED to produce eIDAS compliant
certificates.
Cordialement,
Erwann Abalea
Le 24 août 2016 à 15:05, Moudrick M. Dadashov <[email protected]
<mailto:[email protected]>> a écrit :
eIDAS Article 3 (38):
‘certificate for website authentication’ means an
attestation that makes it possible to authenticate a website
and links the website to the natural or legal person to whom
the certificate is issued;
Thanks,
M.D.
On 8/24/2016 1:08 PM, Adriano Santoni wrote:
But givenName and surname are not sufficient to specify
an identity. How many Robert Smiths exist in UK/US/CA ?
(or Mario Rossi in Italy, as to that).
If I would like to know who's behind a web site whose
SSL cert contains giveName=John, surname=Doe, I am none
the wiser.
Il 23/08/2016 20:02, Bruce Morton ha scritto:
OK, thanks.
Bruce.
*From:*Jeremy Rowley
[mailto:[email protected]
<mailto:[email protected]>]
*Sent:*Monday, August 22, 2016 6:16 PM
*To:*Bruce Morton<[email protected]>
<mailto:[email protected]>;[email protected]
<mailto:[email protected]>
*Subject:*RE: givenName and surname revived
What do you mean by definition? I consider IV v. OV
well defined because of the meaning associated with
the OID inserted into the cert. Section 7.1.6.1
states “{joint‐iso‐itu‐t(2)
international‐organizations(23)
ca‐browser‐forum(140) certificate‐policies(1)
baseline‐requirements(2) individual‐validated(3)}
(2.23.140.1.2.3), if the Certificate complies with
these Requirements and includes Subject Identity
Information that is verified in accordance with
Section 3.2.3.” Section 3.2.3 is verification of an
individual whereas Section 3.2.2 is verification of
an organization.
Jeremy
*From:*Bruce Morton [mailto:[email protected]
<mailto:[email protected]>]
*Sent:*Monday, August 22, 2016 6:11 AM
*To:*Jeremy Rowley <[email protected]
<mailto:[email protected]>>;[email protected]
<mailto:[email protected]>
*Subject:*RE: givenName and surname revived
Hi Jeremy,
My apologies, but can you clarify the section where
IV certs are well defined? I see that
“individual-validated” is stated twice in sections
1.2 and 7.1.6.1 (the same for domain-validated and
organization-validated), but I can’t find the
definition.
Thanks, Bruce.
*From:*Jeremy Rowley
[mailto:[email protected]
<mailto:[email protected]>]
*Sent:*Saturday, August 20, 2016 10:41 AM
*To:*Bruce Morton <[email protected]
<mailto:[email protected]>>;[email protected]
<mailto:[email protected]>
*Subject:*RE: givenName and surname revived
Hey Bruce – IV certs are well defined. The goal of
the ballot isn’t to further define IV certs but to
permit use of the givenName and surname fields for
IV certs. giveName and surname in the org field
would be allowed. They’d still use the IV OIDs as
they were validated under the IV section of the CP.
*From:*Bruce Morton [mailto:[email protected]
<mailto:[email protected]>]
*Sent:*Friday, August 19, 2016 6:41 AM
*To:*Jeremy Rowley <[email protected]
<mailto:[email protected]>>;[email protected]
<mailto:[email protected]>
*Subject:*RE: givenName and surname revived
Hi Jeremy,
Would like some clarification. On the call
yesterday, it was said that IV certificates were not
defined, so this ballot will help resolve this.
Per 7.1.4.2.2 b, the current BRs allow givenName and
surname to be included in the organizationName
field. Will this still be allowed? If so, what would
the certificate type be? OV or IV? I would prefer
that these be OV certificates.
If we do make the changes and the CAs have to meet
Microsoft’s requirement to put a DV, OV, or IV
certificate policy in the certificate, I think we
should clearly define each certificate type.
Also, the stateOrProvinceName field appears to
currently have an issue as it does not have any
language to address the case where there is no state
or province in the address.
Thanks, Bruce.
*From:*[email protected]
<mailto:[email protected]>[mailto:[email protected]
<mailto:[email protected]>]*On Behalf
Of*Jeremy Rowley
*Sent:*Thursday, August 18, 2016 12:09 PM
*To:*[email protected] <mailto:[email protected]>
*Subject:*[cabfpub] givenName and surname revived
Looking for two endorsers for the following
revisions the baseline requirements adding support
for givenName and surname:
Insert a new (C) under 7.1.4.2.2, renumbering all
subsequent bullets.
_c.*Certificate Field*: subject:givenName (2.5.4.42)
and subject:surname (2.5.4.4)_
*_Optional._*
*_Contents: _*_If present, the subject:givenName
field and subject:surname field MUST contain an
natural person Subject’s name as verified under
Section 3.2.3. A Certificate containing a
subject:givenName field or subject:surname field
MUST contain the (2.23.140.1.2.3) Certificate Policy
OID_.
_d._Certificate Field: Number and street:
subject:streetAddress (OID: 2.5.4.9)
Optional if the subject:organizationName field_,
subject: givenName field, or subject:surname field
are_ispresent. Prohibited if the
subject:organizationName field_, subject:givenName,
and subject:surname field are_isabsent.
Contents: If present, the subject:streetAddress
field MUST contain the Subject’s street address
information as verified under Section 3.2.2.1.
_e_. Certificate Field: subject:localityName (OID:
2.5.4.7)
Required if the subject:organizationName
field,_subject:givenName field, or subject:surname
field are_ispresent and the
subject:stateOrProvinceName field is absent.
Optional if the_subject:stateOrProvinceName field
and the subject:organizationName field,
subject:givenName field, or subject:surname _field
are present. Prohibited if the
subject:organizationName field,_subject:givenName,
and subject:surname field are_isabsent.
Contents: If present, the subject:localityName field
MUST contain the Subject’s locality information as
verified under Section 3.2.2.1. If the
subject:countryName field specifies the ISO 3166‐1
user‐assigned code of XX in accordance with Section
7.1.4.2.2(g), the localityName field MAY contain the
Subject’s locality and/or state or province
information as verified under Section 3.2.2.1.
_f_. Certificate Field: subject:stateOrProvinceName
(OID: 2.5.4.8)
Required if the subject:organizationName field
field,_subject:givenName field, or subject:surname
field are_ispresent and_the_subject:localityName
field is absent. Optional if
the_subject:localityName field and the
subject:organizationName field, the
subject:givenName field, or subject:surname
field_are present. Prohibited if the
subject:organizationName field,_subject:givenName
field , or subject:surname field_areisabsent.
Contents: If present, the
subject:stateOrProvinceName field MUST contain the
Subject’s state or province information as verified
under Section 3.2.2.1. If the subject:countryName
field specifies the ISO 3166‐1 user‐assigned code of
XX in accordance with Section 7.1.4.2.2(g), the
subject:stateOrProvinceName field MAY contain the
full name of the Subject’s country information as
verified under Section 3.2.2.1.
_g_. Certificate Field: subject:postalCode (OID:
2.5.4.17)
Optional if the
subject:organizationName,_subject:givenName field,
or subject:surname_fields_are_ispresent. Prohibited
if the subject:organizationName
field,_subject:givenName field, or subject:surname
field are_isabsent.
Contents: If present, the subject:postalCode field
MUST contain the Subject’s zip or postal information
as verified under Section 3.2.2.1.
_h_. Certificate Field: subject:countryName (OID:
2.5.4.6)
Required if the subject:organizationName
field,_subject:givenName , or subject:surname
field_is present. Optional if the
subject:organizationName field,_subject:givenName
field_, and _subject:surname field are_isabsent.
Contents: If the subject:organizationName field is
present, the subject:countryName MUST contain the
two‐letter ISO 3166‐1 country code associated with
the location of the Subject verified under Section
3.2.2.1. If the
subject:organizationName,_subject:givenName field,
and subject:surname_ field_are_ isabsent, the
subject:countryName field MAY contain the two‐letter
ISO 3166‐1 country code associated with the Subject
as verified in accordance with Section 3.2.2.3. If a
Country is not represented by an official ISO 3166‐1
country code, the CA MAY specify the ISO 3166‐1
user‐assigned code of XX indicating that an official
ISO 3166‐1 alpha‐2 code has not been assigned.
_i_. Certificate Field: subject:organizationalUnitName
Optional.
_Contents:_The CA SHALL implement a process that
prevents an OU attribute from including a name, DBA,
tradename, trademark, address, location, or other
text that refers to a specific natural person or
Legal Entity unless the CA has verified this
information in accordance with Section 3.2 and the
Certificate also contains
subject:organizationName,_subject:givenName,
subject:surname,_subject:localityName, and
subject:countryName attributes, also verified in
accordance with Section 3.2.2.1.
7.1.6.1
…
If the Certificate asserts the policy identifier of
2.23.140.1.2.1, then it MUST NOT include
organizationName,_givenName, surname,_streetAddress,
localityName, stateOrProvinceName, or postalCode in
the Subject field.
…
_______________________________________________
Public mailing list
[email protected] <mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
<https://cabforum.org/mailman/listinfo/public>
--
Cordiali saluti, Adriano Santoni ACTALIS S.p.A. (Aruba
Group)
_______________________________________________
Public mailing list
[email protected] <mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
<https://cabforum.org/mailman/listinfo/public>
_______________________________________________ Public
mailing list [email protected]
<mailto:[email protected]>https://cabforum.org/mailman/listinfo/public
<https://cabforum.org/mailman/listinfo/public>
_______________________________________________ Public mailing
list [email protected] <mailto:[email protected]>
https://cabforum.org/mailman/listinfo/public
<https://cabforum.org/mailman/listinfo/public>
--
Erwann.
