[cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements

Ryan Sleevi sleevi at google.com
Tue Nov 24 11:12:51 MST 2020


In the context of OU, including it as a custom extension would violate
7.1.2.4(b), for exactly the reasons it's being discussed to be forbidden.

It is, as the core, as Paul and you have acknowledged: information not
verified by CAs (as it cannot be, as it is fundamentally self-attested with
no externally verifiable source), and which will mislead Relying Parties.

On Tue, Nov 24, 2020 at 1:10 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 24/11/2020 6:01 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Tue, Nov 24, 2020 at 1:34 AM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>> On 24/11/2020 12:34 π.μ., Ryan Sleevi wrote:
>>
>> To use an example, if a CA were to define in its CP/CPS an extension that
>>> follows exactly the description of the *cabfOrganizationIdentifier* as
>>> described in section 9.8.2 of the EV Guidelines (my previous example was
>>> flawed), describe the same EVG validation rules for that extension and
>>> include this extension in an OV Certificate, wouldn't that be compliant
>>> with the BRs?
>>>
>>
>> No, not inherently.
>>
>>
>> I'm sorry for being confused with this response, I was expecting a "yes"
>> because for this example we have documented CABF agreed validation rules,
>> which should unambiguously meet all of BRs 7.1.2.4 requirements. Which
>> part, in your opinion, doesn't fulfill the 7.1.2.4 section? I think it is
>> important to understand this point because if this example doesn't fulfill
>> BRs 7.1.2.4 for custom extensions, I don't know what will.
>>
>
> I suspect this would be better served on our next validation call, since
> we have a tendency to talk past each other in mails. At the core, you
> described a method which, with the information provided, does not satisfy
> 7.1.2.4. If you believe you can define a method that does, then it's up to
> you to document and explain. Unsurprisingly, I am categorically unwilling
> to state "yes" to something that can and will be misconstrued, and in a way
> that can cause users harm. However, it also seems non-germane to the thread
> at hand, and so if you'd like to discuss something concrete, it would
> perhaps best be done in a new thread, to avoid shifting the discussion.
>
>
> I thought it was relevant because of Doug's proposal to make use of a
> custom extension for OU, so I was trying to get some sense of the
> boundaries on using custom extensions in general, as allowed in the BRs. I
> will try to attend the next validation call to discuss further.
>
>
> Thanks,
> Dimitris.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201124/eb49f43d/attachment.html>


More information about the Validation mailing list