Hi there, > On 24 Jun 2020, at 02:55, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Signed PGP part > > Stephen Kent <stkent=40verizon....@dmarc.ietf.org> wrote: >> The simple answer is that when, in the past, developers have chosen to abuse >> the semantics of subject name fields in certs, the result shave been VERY >> long lasting, and embarrassing. Long ago, Netscape chose to shove a DNS name >> into the DN common name filed because it was an easy fix for their >> problem. As a result, we still have browsers and CAs that misuse that >> field. At least that egregious behavior was not the result of an IETF >> WG. Let's not screw this up in the name of expediency! > > Yes, I remember that. > Why do you think Netscape did that? > What should they have done instead? >
Going further, sometimes expedients are appropriate. With the benefit of hindsight of nearly 30 years of experience, there’s a lot that Netscape did in its first years that we wouldn’t do today, but had they not done those things, field delivery could have been delayed by years, probably the worst example being the User-Agent header. We can say, “they never should have done that”, but it was what people deemed necessary and expedient for a number of reasons, not least of which was product differentiation and market maturity. Here we have a situation where the public CA offerings have been made quite brittle. The ability to add either an otherName or a URI requires CAs to modify their code and create alternative roots. We all know that won’t happen, and so that leads to whether an expedient is appropriate. Worse, as I have demonstrated, submitting otherName to public CAs produces garbage in certs (very bad, but there it is). They not only aren’t ready, but they may have potential exploits lingering. Is an expedient appropriate? With ACP it’s clear they are overloading semantics of an rfc822name, and from an application standpoint we don’t like that because it is possible that different subsystems may have different uncoordinated allocation methods. That is- someone may be able to nab an email address via the mail subsystem a la rfcself+fd89b714f3db00000200000064000000+area51.resea...@acp.example.com <mailto:rfcself+fd89b714f3db00000200000064000000+area51.resea...@acp.example.com>, get a cert for that address, and masquerade as an AN or an AN could start sending email as a user that has such an address. Let’s agree that the latter is so minimal a risk as to not warrant further discussion. It’s only the former that’s really of concern. That can be mitigated through operational guidance, a’la “don’t allow email addresses in your domain that begin with rfcSELF+”. It’s not perfect. That’s the nature of an expedient. But it’s probably Good Enough for now. For the eventuality that another name could be used over time, it’s probably worth getting an OID and using otherName where possible, but we shouldn’t hold this work up over a highly theoretical attack. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
