[Servercert-wg] www and non-www (possibly an old issue)

[Doug Beattie]

The www subdomain should not be treated any differently than any other
subdomain, so if a CA includes the "naked" domain, they had better be
validating that domain.

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of
Adriano Santoni via Servercert-wg
Sent: Monday, January 28, 2019 3:59 AM
To: servercert-wg at cabforum.org
Subject: [Servercert-wg] www and non-www (possibly an old issue)

 

All,

I would like to ask your opinion on a possibly old matter.

I apologize if my question will be perceived as a nuisance, but I have
already done some searching for a corroborating rationale and found nothing
really convincing so far, so I prefer not to waste more time when others
here may much more easily and quickly provide the right explanation. 

My question stems from the fact than many CAs automatically include the
naked <domain> in the SAN upon issuing a certificate that was requested for
"www.<domain>" (and the opposite as well), on the grounds of the assumption
that whoever controls "www" also controls the naked <domain>. Now, although
most of the times that above assumption is true _de facto_, I would like to
understand whether there exists an applicable standard (e.g. an RFC) or a
sound technical reasoning, already put down in writing somewhere, supporting
that assumption a priori and in general. 

I kind of sense that it must be true in many cases, but a general
theoretical explanation still escapes me.

Maybe it's obvious, but I can't seem to find it by myself (probably I am not
googling right).

TIA,

Adriano

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190128/ffe29c3b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5701 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190128/ffe29c3b/attachment-0001.p7s>