Re: WebID-ISSUE-5 (bblfish): Follow Work in publishing keys in DNSSEC

> Do you see how it could also be useful
> to bypass CAs, and so to allow self signed certificates to work?

The plugin is currently already able to make /direct/ certificate
associations (meaning: end certificate, no CA's or intermediaries
involved).
So yes. :-)

My example was just to emphasize the importance of the new standards. (Now
you have to use the same certificate/key material on your entire farm)
While I do think it is useful to _be able_ to make the certificate
associations without the involvement of a CA, i also think CA's have
provided a useful service and will continue to do so for a while. The most
powerful trust assertion can be made with a HTTPS host serving a CA-signed
certificate backed by a TLSA record in a DNSSEC signed domain.
Don't discount CA's just yet.

Pieter

> Can I forward this to the mailing list? Or if you want just re-send it to
> public-xg-webid@w3.org
>
> Btw, your example is for a server farm. Do you see how it could also be
> useful
> to bypass CAs, and so to allow self signed certificates to work? Or is
> there
> something that would not make that work?
>
> Henry
>
> On 15 Feb 2011, at 15:38, Pieter Lange wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>> I wonder what the relationship is between the Kaminsky format is, and
>>> what
>>> Dane is proposing. Anyway something to follow here too.
>>
>> You don't have to wonder; we link to both resources. We also took the
>> effort to document both methods (TLSA vs TXT) in their most basic form
>> here: https://os3sec.org/technicalbackground.html
>>
>> Basically it is two methods of publishing your certificate associations.
>> Kaminsky chose not to put entire certificates in DNS because he feels
>> they are too big.
>>
>> Both 'standards' (neither are a real standard yet) allow you to have a
>> serverfarm with individual keys for each server. TLSA does this by
>> allowing you to make a certificate association with a 'parent
>> certificate' or otherwise known as a certificate-signing certificate :).
>> (cert type 3/4)
>> Kaminsky does this by simply looking up a hash of the certificate in DNS
>> (prepending the hash to the hostname) and if ANY signed record exists,
>> the certificate is valid.
>>
>> We chose to also implement Kaminsky's TXT format because it is a nice
>> showcase for what is possible. The ability to make policies such as STS
>> known through DNSSEC is very powerful (and needed) and still missing
>> from the dane spec. I'm sure a decent solution for this will come from
>> the workgroup though.
>>
>> Pieter
>>
>> On 02/15/2011 02:19 PM, Henry Story wrote:
>>> News update. There is a Firefox extension for something very much along
>>> these lines,
>>> as Pieter Lange told me.
>>>
>>> On 15 Feb 2011, at 14:07, Pieter Lange wrote:
>>>
>>>> We recently finished* developing an addon for Firefox 4 beta that does
>>>> DNSSEC validation and pulls certificate associations from DNS in dane
>>>> and/or Kaminsky (TXT) format.
>>>>
>>>> See https://os3sec.org/
>>>>
>>>> Regards,
>>>> Pieter
>>>>
>>>> * Finished -> still development in progress, but it is somewhat
>>>> useable
>>>> at this point.
>>>
>>>
>>> I wonder what the relationship is between the Kaminsky format is, and
>>> what
>>> Dane is proposing. Anyway something to follow here too.
>>>
>>> Henry
>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJNWo//AAoJEEktCr9Rc+j0vKEH/RdrRS3cRfISf9fuxGG2zP8T
>> in1e0ecV2hHw4znCJgtDEY6PcDgSmXgZR4KyWvewVphR20cKz9ZBLrnAVWuwDm3G
>> FtlSBp9cD+gcensiIaYfaquvynf2iQ9SAwKTaoxqSz2+dZobvQH1/hIGb5h4Z/1h
>> uV4mkCek8AtJ792MVH7ZDnOlO3SKHQkYuvNNoyuRF2yw9+FZXCeULXulvVvAPsAL
>> OS0JPJTHTcxpAOtDMRv4BxWebZcFxwIUG0/dkxVKwQj9l54mEQchBXVF70DZCnTT
>> Nx0IvbrmsGsPDSH1oerq8Yn64awUNe/tQmTqzAHMvy3gCnBm3M7o0m6exIb6TCE=
>> =nog6
>> -----END PGP SIGNATURE-----
>
> Social Web Architect
> http://bblfish.net/
>
>

Received on Tuesday, 15 February 2011 22:36:37 UTC