For that matter, can whoever is in charge of gmail.com speak to their intent as to CAA for S/MIME?
I've certainly held certificates which include my personal gmail address before. At no point did I need or seek Google's blessing to do so. I can not imagine that was an uncommon case. (At least, not uncommon relative to the universe of issued S/MIME certificates.) On Mon, May 14, 2018 at 11:13 PM, Neil Dunbar via dev-security-policy < [email protected]> wrote: > > > On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy < > [email protected]> wrote: > > > > If there are proponents of a 'fail open' model, > > especially amongst CAs, then does it behove them to specify as quickly as > > possible a 'fail closed' model, so that we don't have to try and divine > > intent and second guess site operators as to whether they meant to > restrict > > HTTPS or everything? > > While this is in no way comprehensive or scientific, could we not just > poll those (larger) domain owners who also operate publicly available mail > services (like Yahoo) what they consider the scope of their CAA assertions? > There can’t be a super abundance of them, surely? > > I’m no friend of ‘default-allow’ semantics, but I’m also not a fan of > ninja-changing semantics either. If domain owners intended to only express > a company policy on TLS certs (whether HTTPS, LDAP/STARTTLS, IMAP/STARTTLS > or whatever); then might they not be amenable to altering their expression > to an ‘issue(wild)?-tls’ tag instead, but only if they were aware of the > scope of their (in-)actions? > > That would then enable a future move for CAs to respect ‘issue’ and > ‘issuewild’ to cover all cert types, while still allowing domain owners > finer grained expression of their policies. It’s pretty much an entire > reversal of my earlier suggestion(!), but perhaps a modification which > would preserve the expressions of (handwave, handwave) 95% of CAA records > owners who don’t operate public mail services, and yet still can cover > those mail providers? > > But without the courtesy of at least asking those few domain owners what > they meant, it just seems a bit rude to assume their intentions. > > Regards, > > Neil > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
