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]] On Behalf Of Erwann Abalea Sent: Friday, August 26, 2016 1:47 AM To: Moudrick M. Dadashov <[email protected]> Cc: [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]] 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]] 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]] 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]] 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]] 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 areis present. Prohibited if the subject:organizationName field, subject:givenName, and subject:surname field are is absent. 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 thesubject: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 is absent. 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 is present 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 are isabsent. 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 is absent. 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 is absent, 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 -- Cordiali saluti, Adriano Santoni ACTALIS S.p.A. (Aruba Group) _______________________________________________ Public mailing list [email protected]<mailto:[email protected]> https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected]<mailto:[email protected]> https://cabforum.org/mailman/listinfo/public
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
