[cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements
Ryan Sleevi
sleevi at google.com
Tue Nov 24 09:01:13 MST 2020
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20201124/1e212161/attachment-0001.html>
More information about the Validation
mailing list