On 28/11/2017 04:16, Ryan Sleevi wrote:
On Mon, Nov 27, 2017 at 8:29 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 27/11/2017 19:37, Nick Lamb wrote:
On Fri, 24 Nov 2017 12:25:40 +0000
Gervase Markham via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
Validate example.com -> add "www.example.com": seems fine to me, and a
reasonable accommodation to a common customer desire.
Validate www.example.com -> add "example.com": not at all fine.
Validate *.example.com -> add "example.com": still dodgy IMO.
All of these can be a problem, and I would like us to have as the end
goal forbidding all these practices, but I recognise that it's
unrealistic to achieve that in the short term.
The thing is, extraneous names on a certificate present a subtle
security flaw, even if control over those names was validated properly
Extraneous names can appear in a CSR as a result of the applicant
making a bad security choice. But that's not our domain here, bad
choices by Relying Parties or Applicants are their problem. Bad choices
by the CAs can harm everybody and we should be trying to move things in
the right direction on that front.
The inclusion of example.com with *.example.com is a long standing
standard practice based on the fact that most subscribers don't realize
that *.example.com doesn't already cover example.com. The validations
needed for *.example.com are a full superset of those needed for
example.com, with the sole exception that the formal wording of the CAA
specification allows a domain to set up CAA records that allow
*.example.com but prohibit example.com. One could reasonably discuss if
this is a bug in the CAA specification, but until then, CAs are formally
required to check for the scenario and reject the application.
The inclusion of example.com with www.example.com is a tradition, but it
would be good if CAs allowed applicants to deselect it in the rare cases
where they don't intend to use it.
While your scenario below sounds compelling, it is very much a contrived
scenario of the type usually used to trick organizations into making bad
policy decisions.
Due to the cost of publicly trusted certificates, many organizations
could, in the same scenario, obtain just the *.example.com + example.com
certificate and install it on both servers.
Hi Jakob,
Please note the discussion is not about whether it's problematic to include
both, but how you validate. I don't believe anyone has suggested it's not
OK to include both, merely to ensure that the validation performed is
appropriate for both.
Nick Lamb, in the message I replied to, clearly suggested as much, and
provided a contrived scenario to "prove" that point.
It's absolutely intentional that CAA can allow *.example.com and disallow
example.com. This is not something "One could reasonably discuss if this is
a bug", because it's an explicit intentional design choice documented
within the RFC. This isn't even subtle - it's called out. It's not about
being a 'contrived scenario' either - it's about ensuring the appropriate
level of validation.
I was not aware this was an intentional complication by the RFC authors.
I still believe most (not all) occurrences of this CAA record
configuration will be either user error or dedicated CA compliance
tests.
As to your remarks about cost, I think that's about an argument about a
decade out of date, nor particularly germane to the level of security we
should expect from the CA ecosystem.
I am referring to the cost to the certificate subscriber, specifically
the cost of paying for two properly validated certificates rather than
two. Nick Lamb's scenario involved someone deliberately ordering both
*.example.com and www.example.com as separate certificates, along with
other circumstances.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
