The Public Suffix List is a model for failure, not success - and I say that as one of the two PSL maintainers. As to the remaining points, I think each and every one of them doesn't actually hold up to scrutiny, and in fact, the opposite conclusion is more in line with reality.
For example, if anti-spam systems applied per-account algorithms, then there's an incentive for spammers to add themselves to the list. This is demonstrable by some CAs using rate limiting at the PSL boundary, causing a surge in additions to bypass those rate limits - similarly for various browser security mechanisms. Regarding the domain holder acting as behalf as the user - it's absolutely true they can. The position advocated is like suggesting that 3.2.2.4.6 is more secure than 3.2.2.4.2/.3 - the domain holder has primacy over the website operator, and the postmaster has primacy over individual mailboxes. On Mon, May 14, 2018 at 12:10 PM, Jakob Bohm via dev-security-policy < [email protected]> wrote: > Another approach could be to have something akin to the (non-ICANN) > public suffix list, but for e-mail. This would list e-mail domains > where the e-mail address holders are not the subordinates (employees, > students, etc.) of the domain holder. > > Such a list would have multiple uses (just like the public suffix list for > domain delegations): > > 1. E-mails from these domains are not presumed to represent the opinion > of the domain holder in various contexts (including validation of TLS > certs against non-reserved e-mail addresses). > > 2. Anti-spam systems could apply a more per-account algorithm for > computing reputation scores. > > 3. S/MIME certificate issuance does not assume the domain holder can > act on behalf of the e-mail users. Thus validation with > [email protected] would not be valid for [email protected], > but on the other hand CAA records for example.net would not apply > to S/MIME (both if example.net was on the public e-mail domain list). > > > On 14/05/2018 17:48, Neil Dunbar wrote: > >> But it also seems reasonable for organisations making CAA assertions to >> know the scope of their stipulations before they make them, no? >> >> So, if in the case of Yahoo, they make the assertion “All of our web >> certificates should come from DigiCert”, are they aware that they are also >> making the statement “And all of our user mail accounts should only be >> granted S/MIME certificates from DigiCert too”. >> >> Perhaps they are, perhaps not, but I’m willing to bet that a fair number >> of Yahoo accounts have S/MIME certificates not issued by DigiCert - a shift >> to CAA-S/MIME enforcement could cause some unwelcome disruption to Yahoo’s >> customers. >> >> Please note: I’m not opposed to CAA stipulations applying to S/MIME. I >> would just want all participants in the PKI world to know what their >> statements mean and how far they reach. >> >> Since the syntax of CAA is extensible, perhaps ‘issue’ could indeed be >> restricted to TLS certificates, and a newer tag ‘issueall’ be taken to mean >> ‘covering all possible forms of certificates’? >> >> Just a thought, >> >> Neil >> >> On 14 May 2018, at 08:39, Ryan Sleevi via dev-security-policy < >>> [email protected]> wrote: >>> >>> It seems perfectly reasonable and desirable to require that CAs, >>> regardless >>> of the type of certificate they are issuing, respect CAA. >>> >>> If an email provider wishes to restrict some types of certificates (e.g. >>> HTTPS) while allow others (e.g. S/MIME), this could be accomplished >>> through >>> additional expressions within the CAA syntax. >>> >>> However, it would be a long-lasting, and tragic mistake if CAA was >>> presumed >>> to 'only' apply to HTTPS - because it would make the same mistake of >>> nameConstraints - namely, everything that is not expressly listed as >>> permitted/restricted is implicitly permitted - rather than doing what >>> security practitioners have long known is the safe and secure base - >>> forbid >>> unless expressly permitted (default-deny). >>> >>> In terms of order of concerns and constituents, the domain holders needs >>> and security goals outweigh those of the notion of users 'owning' an >>> email >>> address. >>> >>> On Mon, May 14, 2018 at 3:45 AM, Pedro Fuentes via dev-security-policy < >>> [email protected]> wrote: >>> >>> Just to say that looking at this from Europe, I don't see this feasible. >>>> >>>> Citizens getting their personal eIDAS-compliant certificate go through >>>> face-to-face validation and will give virtually any valid e-mail >>>> address to >>>> appear in their certificate. >>>> >>>> El sábado, 12 de mayo de 2018, 2:30:58 (UTC+2), Wayne Thayer escribió: >>>> >>>>> I created a new issue suggesting that we add this requirement to >>>>> Mozilla >>>>> policy: https://github.com/mozilla/pkipolicy/issues/135 >>>>> >>>>> On Wed, May 9, 2018 at 4:59 PM Ryan Sleevi via dev-security-policy < >>>>> [email protected]> wrote: >>>>> >>>>> On Wed, May 9, 2018 at 11:47 AM, Adrian R. via dev-security-policy < >>>>>> [email protected]> wrote: >>>>>> >>>>>> Hello, >>>>>>> this question is somewhat outside the current Baseline Requirements, >>>>>>> >>>>>> but... >>>>>> >>>>>>> >>>>>>> wouldn't it be normal for the same CAA rules for server certificates >>>>>>> >>>>>> to >>>> >>>>> also apply to client certificates when the email address is for a >>>>>>> >>>>>> domain >>>> >>>>> that already has a valid CAA policy published in DNS? >>>>>>> >>>>>>> >>>>>>> RFC 6844 doesn't seem to make any distinction between server and >>>>>>> >>>>>> S/MIME >>>> >>>>> client certificates, it combines them together by referring to >>>>>>> >>>>>> certificates >>>>>> >>>>>>> "for that domain" as a whole. >>>>>>> >>>>>>> >>>>>>> i tested this last night - i obtained an email certificate from one >>>>>>> >>>>>> of >>>> >>>>> the >>>>>> >>>>>>> CAs participating here (not for this exact address though) and it was >>>>>>> happily issued even if CAA records authenticated by DNSSEC do not >>>>>>> >>>>>> allow >>>> >>>>> their CA to issue for this domain. >>>>>>> >>>>>>> Now, this is technically not a mis-issuance because it was a proper >>>>>>> email-validated address and their CPS says that CAA is only checked >>>>>>> >>>>>> for >>>> >>>>> server-type certificates. It doesn't say anything about CAA >>>>>>> >>>>>> validation >>>> >>>>> for >>>>>> >>>>>>> such client certificates. >>>>>>> >>>>>>> I got in touch with them and they seemed equally surprised by such >>>>>>> intended use case for CAA, so my second question is: is anyone >>>>>>> >>>>>> actually >>>> >>>>> checking CAA records for client certificates where an email address >>>>>>> >>>>>> is >>>> >>>>> included in the certificate subject info and the EKU includes Secure >>>>>>> >>>>>> Email? >>>>>> >>>>>>> >>>>>>> >>>>>>> Or is CAA usually checked only for server-type certificates, even if >>>>>>> >>>>>> RFC >>>> >>>>> 6844 refers to certificates "for that domain" as a whole? >>>>>>> >>>>>>> >>>>>> CAs are generally only checking CAA when they're required to in order >>>>>> >>>>> to be >>>> >>>>> trusted. >>>>>> >>>>>> Right now, CAs are only required to check CAA for server-type >>>>>> >>>>> certificates >>>> >>>>> (by virtue of the Baseline Requirements Section 3.2.2.8). >>>>>> CAs are not presently being required to check CAA for e-mail. They >>>>>> >>>>> can, but >>>> >>>>> they are required to do it, so they are unlikely to do it. >>>>>> >>>>> > > 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 > [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
