<div dir="ltr"><div class="gmail_default" style="font-size:small">OK so replying to various comments.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">On the upper case thing, yes of course, its case insensitive. I was cutting and pasting...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">example.com.mb2gk-6duf5-ygyyl-jn5e</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">On the issue of other algorithms, in my UDF scheme, the first byte is a version identifier that can be used to change the digest algorithm and/or the construction. The UDF draft reserves one code for SHA-2-512 and another for SHA-3-512. These have been intentionally chosen so that they give the first characters M (for Merkel-Damguard) or S (for Spongeworthy).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I am currently writing an update tothe UDF spec that proposes using a further 7 version IDs for 'work hardened' fingerprints. If the first 25 bits of your digest value are 0, then you could shorten the fingerprint value by 5 characters and a 15 character fingerprint is sufficiently secure for many purposes. Unfortunately there are patent encumbrances that would have to be settled with the rights holder to use it which may not happen in time to use it for OpenPGP.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">And the digest is not just over the content of the digested message, it is over the digest of a content type identifier (MIME type) and the digest of the content. That makes it possible to use the same scheme for S/MIME and OpenPGP and SSH etc. Or any new thing you want to define.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">In answer to Donald, yes I am being greedy. But not as greedy as the folk asking for $250K per TLD. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Since these are fingerprints, the chance of an accidental collision are very very small, 2^100 for the examples I gave. And those are before fingerprint improvement to 250 bits. I don't think there is any reasonable chance that another DNS address would conflict by accident.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">That said, the request for some sort of mechanism to distinguish the identifiers syntactically may be useful. I did actually consider the ta-- prefix. But I want the fingerprints to look as close as possible to the presentation in other contexts. What we could do is this:<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">example.com.mb2gk<div class="gmail_default" style="font-size:small;display:inline">-</div>-6duf5-ygyyl-jn5e<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">Given that the UDF scheme has internal expansion flexibility built in, the idea that anything that has two dashes at indexes 5 and 6 is a UDF fingerprint seems reasonable to me.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">Alternatively, if we were going to go that route we could make the first 2 characters the version ID giving us 26*36 = 936 possible code points.</div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">So the UDF fingerprint would be m<div class="gmail_default" style="display:inline">f--</div>b2gk<div class="gmail_default" style="display:inline"></div>6<div class="gmail_default" style="display:inline">-</div>duf5<div class="gmail_default" style="display:inline"></div>y<div class="gmail_default" style="display:inline">-</div>gyyl<div class="gmail_default" style="display:inline">-</div>jn5e<div class="gmail_default" style="display:inline">d</div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">example.com.m<div class="gmail_default" style="font-size:small;display:inline">f--</div>b2gk<div class="gmail_default" style="display:inline"></div>6<div class="gmail_default" style="font-size:small;display:inline">-</div>duf5<div class="gmail_default" style="font-size:small;display:inline"></div>y<div class="gmail_default" style="font-size:small;display:inline">-</div>gyyl<div class="gmail_default" style="font-size:small;display:inline">-</div>jn5e<div class="gmail_default" style="font-size:small;display:inline">d</div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 8, 2016 at 12:07 AM, Christian Huitema <span dir="ltr"><<a href="mailto:huitema@huitema.net" target="_blank">huitema@huitema.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Wednesday, September 7, 2016 8:19 AM, Viktor Dukhovni wrote:<br>
> On Wed, Sep 07, 2016 at 10:01:21AM +0200, Phill wrote:<br>
><br>
>> I have a better idea:<br>
>><br>
>> alice@example.com.MB2GK-6DUF5-<wbr>YGYYL-JNY5E<br>
</span>>> ...<br>
> ...<br>
<span class="gmail-">> A difficulty I see is that key rotation becomes difficult to<br>
> impossible. Is the assumption that this key is off-line, and is<br>
> only used infrequently (by the domain owner) to sign other keys<br>
> that do all the interactive work? So it can't be changed withoout<br>
> invalidating saved addresses of this form? (A change of TA, might<br>
> typically mean a change of domain ownership)?<br>
<br>
</span>Yes, that's classic big problem with any scheme using fingerprints as identifiers. The lifetime of keys, and fingerprints, is typically shorter than the lifetime of identities. The classic solution is to have a degree of indirection. On the other hand, the lifetime of email addresses is also shorter than the lifetime of identities. After Alice leaves "Example Co.", he is likely to use a different address than "<a href="mailto:alice@example.com">alice@example.com</a>". In fact, if "Example Co." hires a new employee also called Alice, the email address will be recycled and will point to this new Alice's identity.<br>
<br>
So maybe bundling the address and the fingerprint in a single token is just OK. At least, it has a "failsafe" property. If I send encrypted mail to the old "alice@example.com.MB2GK-<wbr>6DUF5-YGYYL-JNY5E," I know that it will not be readable by the new Alice.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small;display:inline">This is of course spot on. To get the maximum value from this scheme, Alice has to have a fingerprint that is as stable as possible, potentially something that she can keep her whole life.</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">And that is the requirement I have designed the Mathematical Mesh</div> <div class="gmail_default" style="font-size:small;display:inline">to fulfill. The Mesh uses JSON encoding instead of ASN.1 and drops 90% of the junk from PKIX/X.509. But it supports the same type of certificate chaining that CAs use in X.509.</div></div><div><div class="gmail_default" style="font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-size:small;display:inline">So the idea is that Alice has a life-long public key pair that can in principle be kept offline and only used to sign administration keys that are used in her devices to sign application profiles, connect devices to her profile, etc. The only time the master key is ever needed is if Alice has 'messed up' and it is necessary to sign a new administration key. </div></div></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">Of course there may be cases where Alice wants more than one master fingerprint of change her life long fingerprint. But the system is designed on the principle of not forcing this to happen unless it is necessary.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Depending on which fingerprint is used, we can achieve different results.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Let us say that Alice and Example Inc. Both have persistent Mesh profiles. We can create two different addresses:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">alice@example.com.me--<alice fingerprint></div>alice@example.com.me--<<div class="gmail_default" style="font-size:small;display:inline">Example Inc.</div> fingerprint><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small">Which one I wish to use depends on the context in which I am interacting with Alice. In some circumstances I may wish to talk to the Alice I met personally in a previous job. In other circumstances I may wish to contact her as an employee of Example Inc. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The message I send may end up being sent encrypted under different keys as a result. If I am contacting Alice to tell her I have found as zero day bug in a major operating system I may not want Example Inc. to have access to that data. If on the other hand I am conducting a business transaction with Example Inc and there is a contract, it is vital that Example. Inc. have access to that contract and the discussions if Alice falls under a bus.</div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>