[cabfpub] givenName and surname revived
Moudrick M. Dadashov
md at ssc.lt
Tue Aug 30 00:30:36 UTC 2016
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: <http://lists.cabforum.org/pipermail/public/attachments/20160830/831ca344/attachment-0003.html>
More information about the Public
mailing list