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

So when is someone going to make a wintrust provider that uses the dns as cert stores rather than the current cert stores: registry, ldap, smartcards, ...

Wintrust requires one to not only select  the store/container one wants (eg foaf card) but also state how certs shall chain. If the API is set to peer-trust then the provider can tree walk the dns - or ldap, or any other link resolver.



On Feb 15, 2011, at 1:29 PM, Pieter.Lange@os3.nl wrote:

>> 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 23:07:09 UTC