On Fri, May 3, 2013 at 8:15 AM, Leif Johansson <[email protected]> wrote:

>  On 05/03/2013 01:47 PM, Phillip Hallam-Baker wrote:
>
> +1 to the original post and Paul's.
>
>  Putting per user data in the DNS is a lousy approach, it has never been
> a succes because the DNS administrators are typically network admins and
> they are a separate class to DNS admins.
>
> Hey, DNS is just a protocol. I don't think anybody is suggesting
> running end-user data off of bind9 :-)
>
> The critical question is one of trust management: using webfinger
> ties you to the "web pki" for all practical purposes. Using dane ties
> you to the dnssec root.  Personally I'd prefer more options.
>

Then use DANE to authenticate the HTTPS server in the WebFinger
transaction....

--Richard




>
>
>
>
>  A better approach would be to use WebFinger/XKMS/LDAP/TBS to serve up an
> EE cert for the end user and to use DANE to establish a trust anchor under
> which the EE cert is issued.
>
>
>  The amount of email that is protected by message layer security is a
> negligible fraction of that protected by STARTTLS. One of the main reasons
> for that is that the per client user model is fundamentally broken.
>
>
>
> On Fri, Apr 19, 2013 at 5:03 PM, Paul Hoffman <[email protected]>wrote:
>
>> On Apr 19, 2013, at 1:29 PM, Richard Barnes <[email protected]> <[email protected]>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 protected]&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
>>  _______________________________________________
>> dane mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/dane
>>
>
>
>
>  --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> dane mailing [email protected]https://www.ietf.org/mailman/listinfo/dane
>
>
>
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
>
>
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane

Reply via email to