On Wed, Jan 7, 2015 at 10:49 AM, Stephane Bortzmeyer <[email protected]> wrote:
> On Wed, Jan 07, 2015 at 10:42:38AM -0500, > Phillip Hallam-Baker <[email protected]> wrote > a message of 184 lines which said: > > > The simplest URI would simply be either a base64URI or Base32 encoding > of a > > kerberos ticket, a public key or a digest of a public key. > > I do not see immediately the gain from RFC 6698? > Using the DNS to authenticate a connection to a DNS client-resolver connection is a circular dependency. I have no idea how anyone would use DANE to solve the problem of authenticating a service to a client and it is obviously the wrong mechanism for authenticating a client to a service. The TBS scheme provides a direct trust model. These are identifiers that would be used in the presentation layer of the stack and lower. DANE and the WebPKI support indirect trust binding an application layer identifier (aka DNS label) to a key. So the only link I can see to DANE is that you might perform a DANE lookup and then use a TBS URI to represent the information you obtained in the lower layers of the stack. On Wed, Jan 7, 2015 at 12:12 PM, Tony Arcieri <[email protected]> wrote: > On Wed, Jan 7, 2015 at 7:42 AM, Phillip Hallam-Baker < > [email protected]> wrote: > >> TBS::ABAHEA-BI4AAJ-6ACOXQA-A7AHPD-KAHDAES-NZACVA-HGWMAJ-DAA >> > > What serialization format is this? > > Why not URI-safe Base64, as in e.g.: > > https://tools.ietf.org/html/rfc6920 > It is the 'for the sake of example' serialization scheme. The precise scheme does not matter a great deal. I was in the Apple store getting my iPhone fixed with 4 minutes of battery remaining and I cut and pasted from my most recent draft. The design constraint motivating the use of Base32 over Base64uri was to permit the key identifier to be prepended to an email address and they are not case sensitive. That does not apply here of course. But it might be desirable to permit easy interchange between the two. The other argument for BASE32 is that this is an identifier that might have to be read aloud over a telephone or voice connection. I am aware of RFC6920 of course, I am an author. This is a distinct scheme in that the ni scheme is saying 'here is a resource identified by this digest' and in this scheme we are identifying a key that can be used to authenticate an account holder. I have no objection to using the same format for the serialization but it is actually a different URI scheme because the semantics are very different.
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
