Right.
As a reminder, the proposed resolution is as follows:
* Do not establish a registry now
Let the first new header field specification establish it
* A client that gets an unknown field ignores it
This means no mandatory-to-understand extensions
At this stage, a +1 response is OK though not necessary (we got plenty of those
in the room), but any disagreement should come with an explanation.
Thanks
Yoav
================================================================
From: websec-boun...@ietf.org [mailto:websec-boun...@ietf.org] On Behalf Of
Barry Leiba
Sent: Tuesday, August 14, 2012 7:14 AM
To: IETF WebSec WG
Subject: Re: [websec] handling STS header field extendability
Please forgive my ignorance, but do LockCA and/or LockEV offer any
functionality that you can't already get with public key pinning as
currently specified?
Folks, this thread has rather been hijacked. We need to have some WG input on
what registration policy to recommend for a possible future STS header field
registry. That's what this thread is for, and I need to see some WG discussion
about it in order that Jeff may finish the document and that I may move it
forward.
Please take discussion of LockCA and LockEV to another thread.
Thanks,
Barry
_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec
