[cabfpub] Ballot 167 - Baseline Requirements Corrections

Ryan Sleevi sleevi at google.com
Thu Apr 7 08:53:37 UTC 2016

On Thu, Apr 7, 2016 at 1:23 AM, Ryan Sleevi <sleevi at google.com> wrote:

> On Thu, Apr 7, 2016 at 1:08 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
>  wrote:
>> I see. I was probably confused because the profiles of and
>> already include the subject extension, what information should be
>> included in specific fields (countryName, organizationName) and also
>> mention how this information is verified with references to 3.2.2.* at
>> least in this cleanup proposal.
> Correct, and it's that asymmetry that I think is (also) mistaken and needs
> to be cleaned up.
>> I must admit from a CA perspective that having all information in one
>> section (profile options, which option is optional/required and validation
>> references for each option) makes things very clear. The more references we
>> have, the worse it gets.
> The arguable benefit here is that the proposed split (also covers/can
> covers) cases where, say, there's a distinguishedName in a
> [subject/issuer]alternative name.
> At fundamental question is whether a field like "countryName" should
> always be validated consistently between certificate types (... yes?), and
> whether it should be permissible for, say, a technically constrained subCA
> certificate (which is arguably a 'subordinate CA' certificate) can also
> contain, say, no SAN and a CN for "www.google.com". Under Peter's/your
> proposal, that would appear to be a valid action, and that's why I think
> it's buggy.
> The alternative, coupling it all into a table (DN name type, validation
> method, required for root, required for subCA, required for end-entity)
> means that you've got even more information with a growing number of
> permutations, which can't scale well to accommodate additional certificate
> types, and can't scale well to handle the general appearance of name forms
> in other contexts.
> That's why I suggested the split I did
> - Validation procedures collect multiple pieces of information, and may
> include things like a QGIS (which could return DBA name, jurisdiction of
> incorporation, serial number, etc)
> - Certificate profiles, which will necessarily vary between the types of
> certificates (for example, consider the myriad ETSI profiles here)
>   - This also aligns with the push by Microsoft to split DV/OV/IV/EV
> profiles into their respective policy OIDs, which also necessitates varying
> profiles as to which fields (like jurisdictionOfEncorporation) are
> mandatory, and under which profiles
> - Name forms, which will hopefully be universal - for example,  you don't
> want organizationName to be arbitrary data for a sub-CA certificate, but
> the legal entity name for an OV certificate; because now it means all
> relying parties now have to know under which context and profile to
> interpret information
> Anyways, this is largely why I suggested a separate ballot - the changes
> are bigger in scope, there's subtleties to discuss, and, as you noted,
> cross-references to validate.
> To save Peter a roundtrip - if the ballot from
> https://cabforum.org/pipermail/public/2016-April/007170.html was amended
> once more to remove the following statement "Append " - Subscriber
> Certificates" to the the title of section" - would you be willing
> to endorse that ballot?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160407/6574911a/attachment-0003.html>

More information about the Public mailing list