[cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements
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
188.8.131.52(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 184.108.40.206 requirements. Which
>> part, in your opinion, doesn't fulfill the 220.127.116.11 section? I think it is
>> important to understand this point because if this example doesn't fulfill
>> BRs 18.104.22.168 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
> 22.214.171.124. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation