<p dir="ltr"><br>
Den 7 sep 2016 11:36 skrev "Phill" <<a href="mailto:hallam@gmail.com">hallam@gmail.com</a>>:<br>
><br>
> A while ago, I proposed a new form of ‘strong email address’ that combined a PGP fingerprint like identifier with an email address:<br>
><br>
> MB2GK-6DUF5-YGYYL-JNY5E?<a href="mailto:alice@example.com">alice@example.com</a><br>
><br>
> The idea of this scheme is that MB2GK-6DUF5-YGYYL-JNY5E is the fingerprint of a key under which a policy for sending mail to <a href="mailto:alice@example.com">alice@example.com</a> is signed. That might have statements like ‘emails must be signed’, ‘use PGP’, etc. [...]</p>
<p dir="ltr">> I have a better idea:<br>
><br>
> alice@example.com.MB2GK-6DUF5-YGYYL-JNY5E [...]</p>
<p dir="ltr">I'd like to make minor modifications. </p>
<p dir="ltr">First, many systems that would be incompatible uses simple regexp of similar in the string. That would likely (favorably) cut out the end of an appendix using an invalid first character in the domain, such as using ; (semicolon) as the separator, so that the system still can communicate with it. </p>
<p dir="ltr">Although I'm not sure if too many systems would outright not allow you to enter it (I've seen plenty examples of that, still forcing the user to edit it out manually. But are these systems significantly more common than systems that simply have length limits that would *also* deny it? (I'll have to admit that this first point is more bikeshedding than anything else, unless somebody can bring data...) </p>
<p dir="ltr">Second, shouldn't we allow for changing ciphers? As an example, Bitcoin already uses the prefix 1 to signify an address using ECDSA secp256k1 encoded in a particular way with double hashing. The prefix 3 signifies a hashed script which itself can invoke secp256k1, SHA256 or any potential future algorithm additions. More prefixes can be added if necessary. All we need to do here is to define prefixes that identify ciphersuites. </p>
<p dir="ltr">We don't need to define more than one or require the support for more than one default choice (we don't need a new TLS mess), the point is simply to enable a transition without breaking compatibility if the previous choice of cipher becomes insecure. Perhaps to be able to switch to a post quantum cipher suite in a near future. A system seeing an address with unsupported ciphers could suggest that the user checks for any available software updates to potentially add support for it. </p>
<p dir="ltr">> The chief security issue here is that if we are talking about <a href="mailto:alice@eop.gov">alice@eop.gov</a> or <a href="mailto:alice@microsoft.com">alice@microsoft.com</a> or the like, we want to make sure that we are talking to the implied domain if it matters. Which is something that enterprises can do with an appropriate CAA record requiring messages to that domain be supported by a suitably validated cert.</p>
<p dir="ltr">We can tie into DNSSEC+DANE, perhaps make it a requirement for clients using this scheme. Not that it matters much if the message is encrypted. <br></p>