Re: [websec] Service auto-configuration and certificate pinning

As a totally different alternative for non-HTTP pinning, please take a 
look at 
https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/. I 
the meantime I have also prototyped an implementation by forking the 
"mint" TLS 1.3 code, 
https://github.com/yaronf/mint/blob/master/README-pinning.md

Thanks,
     Yaron

On 24/06/16 00:26, Marten Gajda wrote:
> 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, D.Rogers@gmx.net wrote:
>>> Hello Marten,
>>> it might be of interest to check out the 'Unbearable' group. they are working on
>>> pinning bearer certficates.
>> For info: unbearable@ietf.org 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" <marten@dmfs.org>
>>> *An:* "websec@ietf.org" <websec@ietf.org>
>>> *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: marten@dmfs.org
>>>
>>> Managing Director: Marten Gajda
>>> Registered address: Dresden
>>> Registered No.: AG Dresden HRB 34881
>>> VAT Reg. No.: DE303248743
>>>
>>> _______________________________________________
>>> websec mailing list
>>> websec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/websec
>>>
>>>
>>>
>>> _______________________________________________
>>> websec mailing list
>>> websec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/websec
>>>