[SSL Observatory] DFN and subordinate CA domain-scoped whitelists

[Phillip Hallam-Baker]

Actually I had just done so above.

The problem with hotlists is that they assume a much higher level of
cultural awareness than may exist. So part of the reason for having CAA is
to do away with hotlists. So this is another area where maybe some hotlist
functionality is required. Can it be brought in scope of CAA? Perhaps even
just as a 'don't issue these automatically, take a second look'.


The problem with local as I see it is:

1) People need certs to do SSL
2) People want to do SSL on their .local hosts

If we want a prohibition to stick we should maybe consider how we would
want .local to be handled in a way that allows use of crypto but does not
give false security indicators?


On Wed, Nov 9, 2011 at 10:47 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net>wrote:

> On 11/09/2011 10:20 AM, Phillip Hallam-Baker wrote:
> > I am not sure that owning example.com should allow someone to establish
> a
> > prohibition issue of certs to example.com.**.com.
>
> It's not clear to me who you think suggested this;  i certainly didn't,
> and i think it would be a terrible idea.
>
> My use of this "prefix-style" approach to the sAN was as an attempt to
> scatter some chaff to distract from the public/global name "hidden" in
> the sAN list.
>
> My concern is that the CAs in question appear to be signing certificates
> for names that do not have any domain suffix at all, or have a suffix
> (like .local) known to be used in a colliding fashion by many people.
>
> I'm baffled by the idea that any CA would think it reasonable to sign a
> .local name for a certificate of any duration, let alone a 5 year duration.
>
>        --dkg
>
>
>


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/observatory/attachments/20111109/515a5cb7/attachment.html>