Thanks to the both of you. I'll have a closer look into that. On a first glance it looks indeed very interesting.
Cheers, Marten Am 23.06.2016 um 11:14 schrieb Stephen Farrell: > > On 23/06/16 09:54, [email protected] wrote: >> Hello Marten, >> it might be of interest to check out the 'Unbearable' group. they are >> working on >> pinning bearer certficates. > For info: [email protected] is the WG mailing list. The working > group is more prosaically named tokbind. [1] :-) > > S. > > [1] https://tools.ietf.org/wg/tokbind > >> Regards >> Dean Rogers >> *Gesendet:* Mittwoch, 22. Juni 2016 um 23:38 Uhr >> *Von:* "Marten Gajda" <[email protected]> >> *An:* "[email protected]" <[email protected]> >> *Betreff:* [websec] Service auto-configuration and certificate pinning >> Hi list, >> >> I'm currently working on an update of a draft that specifies a way for >> clients to configure themselves with a minimum of user-provided >> information. The current draft is available at >> https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 >> (it's a bit outdated, but we're working on it). >> This draft specifies a member to contain a server certificate, which >> presumably was meant to support some sort of certificate pinning. >> >> During my research on how to improve this I came across RFC 7469 and >> https://tools.ietf.org/html/draft-hallambaker-webseccaa-00 >> >> I'd like to ask the members of this list whether they think that >> "bootstrapping" certificate pinning for individual services (like so: >> https://github.com/CalConnect/AUTODISCOVERY/issues/8#issuecomment-227857982) >> would be useful to have in a service configuration document or if they >> have any concerns or other comments about this. >> >> I'd also like to hear about opinions if this could be an acceptable >> solution for certificate pinning with non-HTTP based protocols, i.e. for >> protocols that don't have an in-band pinning mechanism the client would >> reload the service configuration document whenever the cached pinning >> information is outdated (i.e. <max-age> seconds have passed since it was >> downloaded). >> >> Any comments (whether in response to this post or at GitHub) are very >> welcome. >> >> Regards, >> >> Marten Gajda >> >> -- >> Marten Gajda >> CEO >> >> dmfs GmbH >> Schandauer Straße 34 >> 01309 Dresden >> GERMANY >> >> phone: +49 177 4427167 >> email: [email protected] >> >> Managing Director: Marten Gajda >> Registered address: Dresden >> Registered No.: AG Dresden HRB 34881 >> VAT Reg. No.: DE303248743 >> >> _______________________________________________ >> websec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/websec >> >> >> >> _______________________________________________ >> websec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/websec >> -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: [email protected] Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
