[cabfpub] Revised document for Ballot 89 - Adopt Requirements for the Processing of EV SSL Certificates v.2

[Ryan Sleevi]

On Thu, Oct 11, 2012 at 5:31 PM, Rick Andrews <Rick_Andrews at symantec.com>wrote:

>  Colleagues,
>
> I’ve updated the document again to include feedback from Kathleen. I
> changed the title back to Guidelines as opposed to Requirements, and
> changed a lot of musts to shoulds.
>
> Please look it over again, especially browser members. If we have
> consensus on this version, I’ll advance it towards a ballot. Thanks,
>
> -Rick
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
Rick,

Thanks for taking the time to incorporate the feedback raised by the
browser members. I think this is a very positive step forward in the
document.

I don't have strong feelings on the matter, and certainly haven't
implemented anything to the effect, but I wonder what the proposed changes
to Section 9 mean for systems that implement DANE Type 3 validation (that
is, where DNSSEC is used to obtain the public key, independent of CA trust
anchors). Under such scenarios, it seems like there would be some middle
ground in the UI between a full EV indication, and the proposed change
which is "no secure indicator".

I certainly agree that if RFC 5280 / EV Treatment hasn't been followed,
there should be no EV branding, but I'm not sure whether it's necessary to
fully strip any security indicator - particularly if using any
application-defined or non-RFC5280 validation logic (again, eg: DANE). I
see three levels of validation here (with three possible UI brands) - EV,
DV, DANE - and the current text seems to suggest that only EV/DV should be
used.

The original text (sans proposed addition) handled the above scenario fine,
but I'm curious for your thoughts as to what you think the expected
behaviour should be for such situations. I'll note this same concern also
applies to the proposed "and should not be treated as trusted certificates"
for section 13.

For section 13 "but should try the GET method first" - perhaps "should
prefer the GET method". This is by no means a sticking point, but it just
seems to conflict with the "may use either" implies they could only use
POST. "should prefer" provides directions both for implementation and
prioritization of the attempt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cabforum.org/pipermail/public/attachments/20121011/32ee5b07/attachment.html