[cabfpub] Ballot 167 - Baseline Requirements Corrections

Ryan Sleevi sleevi at google.com
Thu Apr 7 08:54:06 UTC 2016


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

> Drat, and I just realized you dropped the CA/B forum list midway in this
> thread.
>
> Would you object to me reposting each of these messages?
>
> 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 7.1.2.1 and
>>> 7.1.2.2 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 7.1.4.2." - would you be willing
>> to endorse that ballot?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160407/d4855983/attachment-0003.html>


More information about the Public mailing list