OK, permit givenName and surname, and also permit O field now since CA need time to update the system. This ballot is for our IV SSL comply with BR that we don't like to use O field to confuse site visitor.
Regards, Richard > On 20 Aug 2016, at 11:33, Jeremy Rowley <[email protected]> wrote: > > I don’t agree with this. We should permit givenName and surname for now, but > still permit O fields. There isn’t a good reason to switch over until after > we’ve seen the impact of moving to givenName and surname instead of the O > field. The language for the state/locality is the same. An IV or OV cert > requires either a state or locality. The OIDs are already clearly defined > under Section 7.1.6.1 of the BRs. This wouldn’t change. > > Jeremy > > From: [email protected] [mailto:[email protected]] On > Behalf Of Richard Wang > Sent: Friday, August 19, 2016 9:42 AM > To: Bruce Morton <[email protected]> > Cc: [email protected] > Subject: Re: [cabfpub] givenName and surname revived > > See below inline, thanks. > > Regards, > > Richard > > On 19 Aug 2016, at 20:40, Bruce Morton <[email protected]> wrote: > > 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. > > R: I think we need to update this item in the same time that the givenName > and surname to be included in the organizationName field is not allowed. This > will confuse the site visitor think the personal name is a registered company > name. > > > > > 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. > > R: Yes. > > > > 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. > > R: I think locality and state/province must have one. > > > > Thanks, Bruce. > > From: [email protected] [mailto:[email protected]] On > Behalf Of Jeremy Rowley > Sent: Thursday, August 18, 2016 12:09 PM > To: [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 is 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 is present 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 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 is absent. > 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 is present. 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 is absent. > 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] > https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
