Subject: [dane] To DANE or to WebFinger?

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Apr 2013 16:29:05 -0400

Just a thought: It might be simpler to do S/MIME certificate discovery
using WebFinger than using DANE.  You would just have to do an HTTPS query
to a URI of the  form...

<
https://example.com/.well-known/webfinger?resource=mailto:[email-masked]&rel=certificate

... then parse a JSON object to find the certificate.  As opposed to having
an appropriately upgraded DNS library, being able to do DNSSEC, and parsing
the binary record format.

This process could still benefit from DANE, via TLSA validation on the
HTTPS connection.  And basically the only documentation you would need
would be to define the "certificate" relation type.

Like I said, just a thought.

--Richard

---

From: Tony Finch <[email-masked]>
Date: Fri, 19 Apr 2013 21:44:07 +0100

> the binary record format.

And this avoids the problem of how to map email addresses into DNS owner
names when you don't know enough about the other site's local part
semantics.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 19 Apr 2013 14:03:56 -0700

On Apr 19, 2013, at 1:29 PM, Richard Barnes <[email-masked]> wrote:

> Just a thought: It might be simpler to do S/MIME certificate discovery using WebFinger than using DANE.  You would just have to do an HTTPS query to a URI of the  form...
> 
> <https://example.com/.well-known/webfinger?resource=mailto:[email-masked]&rel=certificate>
> 
> ... then parse a JSON object to find the certificate.  As opposed to having an appropriately upgraded DNS library, being able to do DNSSEC, and parsing the binary record format.

That might be a good way to do certificate discovery, but not really a good way to have a second trust anchor if one wanted to get away from the distributed PKIX hierarchies.

There are plenty of ways to do certificate discovery. The question is how to be sure that the certificate you get is one you want to use.

> This process could still benefit from DANE, via TLSA validation on the HTTPS connection.  And basically the only documentation you would need would be to define the "certificate" relation type.

Um, doesn't that wipe out the supposed advantages you list above?

--Paul Hoffman

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Apr 2013 17:13:59 -0400

On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman <[email-masked]> wrote:

> > ... then parse a JSON object to find the certificate.  As opposed to
> having an appropriately upgraded DNS library, being able to do DNSSEC, and
> parsing the binary record format.
>
> That might be a good way to do certificate discovery, but not really a
> good way to have a second trust anchor if one wanted to get away from the
> distributed PKIX hierarchies.
>
> There are plenty of ways to do certificate discovery. The question is how
> to be sure that the certificate you get is one you want to use.

The benefit of this one is that you don't actually need the cert.  You
could just provision a public key this way.  The binding of the public key
to the identity is done by virtue of the the fact that the web server
represents "example.com".  It's conceptually the same as if you had put a
TA in DNSSEC, it just routes through the HTTPS cert.

DANE: DNS Root --DNSSEC--> example.com --DANE--> example.com S/MIME TA
--PKIX--> id/key binding
WebFinger: DNS Root --DNSSEC--> example.com --DANE--> example.com TLS TA
--WebFinger--> id / key binding

> Um, doesn't that wipe out the supposed advantages you list above?

It pushes them down the stack.  The TLS layer uses DANE; the application
layer doesn't.  You still have to be able to do DNSSEC if you want DANE for
the HTTPS connection, but you don't have to.

--Richard

---

From: Tony Finch <[email-masked]>
Date: Fri, 19 Apr 2013 22:29:45 +0100

> TA in DNSSEC, it just routes through the HTTPS cert.

How do you represent this relationship in a form you can verify offline?

Tony.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Apr 2013 17:54:17 -0400

> How do you represent this relationship in a form you can verify offline?

With public keys, you wouldn't.

With PKIX, you could have WF assert a TA for the domain, just like DANE.

--Richard

> --
> f.anthony.n.finch  <[email-masked] <javascript:;>>  http://dotat.at/

---

From: Leif Johansson <[email-masked]>
Date: Sat, 20 Apr 2013 11:03:19 +0200

> That might be a good way to do certificate discovery, but not really a good way to have a second trust anchor if one wanted to get away from the distributed PKIX hierarchies.
Exactly.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Apr 2013 20:31:34 -0400

As mentioned elsewhere, you could just as well have the WebFinger resource
assert a TA for email within the domain.

GET /.well-known/webfinger?resource=mailto:[email-masked]/1.1
Host: example.com

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/jrd+json

{
  "subject" : "mailto:[email-masked]",
  "properties" :
  {
      "smime-certificate" : "blob of base64",
      "smime-trust-anchor" : "blob of base64"
  },
}

On Sat, Apr 20, 2013 at 5:03 AM, Leif Johansson <[email-masked]> wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>