
DigiCert in-addr.arpa X.509 certificate mis-issuance - fanf2
https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/JFwqZx7RLL0
======
0x0
Previous discussion:
[https://news.ycombinator.com/item?id=19284934](https://news.ycombinator.com/item?id=19284934)

------
peterwwillis
TIL: DigiCert uses manual processes for issuing certs which can be taken
advantage of to mis-issue them.
([https://groups.google.com/forum/#!msg/mozilla.dev.security.p...](https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/JFwqZx7RLL0/ctOjU-v5AAAJ))

Also it seems like people are leaning towards replacing WHOIS with DNS, which
seems like a great fix for their operational problems, but probably a security
mistake.

~~~
geofft
Of course there are manual processes - there's a huge market for people who
legitimately need certificates but cannot/will not automate everything.
Otherwise everyone would have left the business after Let's Encrypt entered.
You're not paying DigiCert for the cert itself - LE can give you that - you're
paying them for having customer service, aka manual processes.

It looks like this particular process exists because automating WHOIS lookups
is hard/unreliable. An agent does a WHOIS lookup, documents it, and passes the
result to other people to review. That genuinely seems to be the best way to
deal with poor-quality databases that have the right data.

Also it seems pretty natural to me that some business is going to ask for a
certificate for www-staging.example.com or something, prove ownership in a way
that happens to demonstrate ownership of example.com, and then be mad on
launch day when www.example.com doesn't have a certificate too. So there
should be a way for an agent to say "It looks like they control example.com"
and authorize that, as long as there's review in place.

~~~
tialaramex
We should avoid having human agents making these determinations because
they're very bad at it. Play to human strengths. The human agent working
around the fact that you keep saying "Apache" but you're actually clearly
running IIS from your description is where humans are good, training an AI
system to figure this out would be really hard. Figuring out that .in-
addr.arpa is a Public Suffix and therefore you cannot possibly prove control
over it from a Web PKI point of view is just trivial string matching and
perfectly suited to a machine.

We already have had incidents where a CA mistakenly took proof of control of
one-name.example.com as sufficient proof of control of example.com itself and
it's part of why Facebook freaked out before we had mandatory CAA (and before
Facebook wrote themselves CAA records) because a sub-contractor got themselves
a certificate Facebook didn't intend to exist. So no more of that please.

~~~
geofft
You should be allowed to register a public suffix - github.io is a public
suffix, but the *.github.io wildcard is a perfectly legitimate certificate.
And conversely facebook.com is not a public suffix, so that rule wouldn't have
helped Facebook.

I agree a public suffix should trigger more aggressive validation (as should,
perhaps, the first request for a TLD that the CA has never issued for before),
but I don't think a computerized rule blocking registration of public suffixes
is appropriate.

~~~
tialaramex
The Baseline Requirements forbid issuing for Public Suffixes in what the PSL
calls the "ICANN DOMAINS" section (or wildcards immediately under those
suffixes). That section includes in-addr.arpa but not github.io

Now, the BRs don't specifically tell you not to validate in-addr.arpa and then
issue more specific certificates, but my patience wears very thin on how much
needs to be spelled out letter by letter to have CAs stop doing things that
are obviously a terrible idea.

I can see how the juxtaposition was confusing. Facebook wasn't concerned about
public suffix problems, they were worried by (a historically common) pattern
where bad guys find that if they're able to persuade a CA to issue them with
some-machine.example.com the same CA will then issue www.example.com to them
because hey, they're from example.com... It so happened in the case that
worried them that couldn't have happened, but they were not to know that.

~~~
geofft
Oh, I forgot about the two classes of public suffix - and yes, if the BRs
categorically forbid it and it's on an intentionally-machine-parseable list,
then I agree there's no excuse for allowing issuance before a software upgrade
to explicitly carve out an exception.

