[cabfpub] givenName and surname revived
Moudrick M. Dadashov
md at ssc.lt
Thu Sep 1 13:46:07 MST 2016
Bonjour, Erwann, please see below..
On 8/30/2016 12:54 PM, Erwann Abalea wrote:
> Bonjour,
>
> My reading is that 319412-1 lists the different certificate profiles
> and defines semantic identifiers to be used for natural (in
> serialNumber) and legal (in organizationIdentifier) persons in other
> 319412-x profiles when necessary; 319412-2 and -3 are *NOT* suited to
> website certificates, 319412-4 is the one to use for websites,
> 319412-5 specifies requirements for the QCStatements extension.
319412-2: 1 Scope - The present document specifies requirements on the
content of certificates issued to natural persons. This profile builds
on IETF RFC 5280 [1] for generic profiling of Recommendation ITU-T X.509
| ISO/IEC 9594-8 [i.3]. This profile supports the requirements of EU
Qualified Certificates as specified in the Regulation (EU) No 910/2014
[i.5] ***as well as other forms of certificate***. The scope of the
present document is primary limited to facilitate interoperable
processing and display of certificate information.
319412-3: 1 Scope - The present document specifies a certificate
profile for certificates issued to legal persons. The profile defined in
the present document builds on requirements defined in ETSI EN 319 412-2
[2]. The present document supports the requirements of EU qualified
certificates as specified in the Regulation (EU) No 910/2014 [i.3] ***as
well as other forms of certificate***.
>
> 319412-4 basically says « follow CABF BR for website certificates
> issued to legal or natural persons, or CABF EVG for website
> certificates issued to legal persons, and if the certificate is
> Qualified, add the QCStatements extension as described in 319412-5 »
> (you can also add the QCStatements extension in a non Qualified
> certificate).
Indeed.
>
> BR in section 7.1.4.2.2 lists the attributes found in the subject
> name, and its item (i) allows for other attributes. So you can add a
> serialNumber or organizationIdentifier attribute, it’s BR-compliant.
> Ballot 175 (if/when adopted) will clarify the givenName/surName
> presence, which should be fine.
Right, but the BR/EVG vs ETSI (id-etsi-qcs-SemanticsId triggered) serial
number have different syntax (and possible values). Do we know any
browsers supporting this today?
At the end we have two certs issued to the same Subject by the same CA
with different (serial number) notations and most probably different
values. How about harmonizing this?
Thanks,
M.D.
>
> EVG in section 9.2 does the same for EV certificates, and section
> 9.2.8 also allows other attributes to be filled in. You’re then
> allowed to add the organizationIdentifier attribute, in addition to
> the already present serialNumber. See them as duplicate information
> (organizationIdentifier contains jurisdiction*Name and serialNumber
> altogether, in a sense).
>
> BR in section 7.1.2 sets requirements on certificate extensions, and
> section 7.1.2.4 allows for other extensions to be added. So the
> QCStatements extension can be added if you want, considering that you
> (as a CA) are « aware of a reason for including the data in the
> Certificate », and that this extension will not « mislead a Relying
> Party about the Certificate information verified by the CA ».
>
>
> Cordialement,
> Erwann Abalea
>
>> Le 30 août 2016 à 02:30, Moudrick M. Dadashov <md at ssc.lt
>> <mailto:md at ssc.lt>> a écrit :
>>
>> Right, the question is whether the Subject field value, presented in
>> accordance with id-etsi-qcs-SemanticsId, remains BR/EVG compliant.
>>
>> Thanks,
>> M.D.
>>
>> On 8/29/2016 10:10 PM, Erwann Abalea wrote:
>>> (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 <Kirk.Hall at entrust.com
>>> <mailto:Kirk.Hall at entrust.com>>:
>>>
>>> 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:*public-bounces at cabforum.org
>>> <mailto:public-bounces at cabforum.org>
>>> [mailto:public-bounces at cabforum.org
>>> <mailto:public-bounces at cabforum.org>] *On Behalf Of *Erwann Abalea
>>> *Sent:* Friday, August 26, 2016 1:47 AM
>>> *To:* Moudrick M. Dadashov <md at ssc.lt <mailto:md at ssc.lt>>
>>> *Cc:* public at cabforum.org <mailto:public at cabforum.org>
>>> *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 <md at ssc.lt
>>> <mailto:md at ssc.lt>> 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:jeremy.rowley at digicert.com
>>> <mailto:jeremy.rowley at digicert.com>]
>>> *Sent:*Monday, August 22, 2016 6:16 PM
>>> *To:*Bruce Morton<Bruce.Morton at entrust.com>
>>> <mailto:Bruce.Morton at entrust.com>;public at cabforum.org
>>> <mailto:public at cabforum.org>
>>> *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:Bruce.Morton at entrust.com
>>> <mailto:Bruce.Morton at entrust.com>]
>>> *Sent:*Monday, August 22, 2016 6:11 AM
>>> *To:*Jeremy Rowley <jeremy.rowley at digicert.com
>>> <mailto:jeremy.rowley at digicert.com>>;public at cabforum.org
>>> <mailto:public at cabforum.org>
>>> *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:jeremy.rowley at digicert.com
>>> <mailto:jeremy.rowley at digicert.com>]
>>> *Sent:*Saturday, August 20, 2016 10:41 AM
>>> *To:*Bruce Morton <Bruce.Morton at entrust.com
>>> <mailto:Bruce.Morton at entrust.com>>;public at cabforum.org
>>> <mailto:public at cabforum.org>
>>> *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:Bruce.Morton at entrust.com
>>> <mailto:Bruce.Morton at entrust.com>]
>>> *Sent:*Friday, August 19, 2016 6:41 AM
>>> *To:*Jeremy Rowley <jeremy.rowley at digicert.com
>>> <mailto:jeremy.rowley at digicert.com>>;public at cabforum.org
>>> <mailto:public at cabforum.org>
>>> *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:*public-bounces at cabforum.org
>>> <mailto:public-bounces at cabforum.org>[mailto:public-bounces at cabforum.org
>>> <mailto:public-bounces at cabforum.org>]*On Behalf
>>> Of*Jeremy Rowley
>>> *Sent:*Thursday, August 18, 2016 12:09 PM
>>> *To:*public at cabforum.org <mailto:public at cabforum.org>
>>> *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
>>>
>>> Public at cabforum.org <mailto:Public at cabforum.org>
>>>
>>> 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
>>>
>>> Public at cabforum.org <mailto:Public at cabforum.org>
>>>
>>> https://cabforum.org/mailman/listinfo/public
>>> <https://cabforum.org/mailman/listinfo/public>
>>>
>>> _______________________________________________ Public
>>> mailing list Public at cabforum.org
>>> <mailto:Public at cabforum.org>https://cabforum.org/mailman/listinfo/public
>>> <https://cabforum.org/mailman/listinfo/public>
>>>
>>> _______________________________________________ Public mailing
>>> list Public at cabforum.org <mailto:Public at cabforum.org>
>>> https://cabforum.org/mailman/listinfo/public
>>> <https://cabforum.org/mailman/listinfo/public>
>>>
>>> --
>>> Erwann.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160901/6c158933/attachment-0001.html
More information about the Public
mailing list