Re: [websec] handling STS header field extendability

Yoav Nir <> Tue, 14 August 2012 07:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61D7621F85C4 for <>; Tue, 14 Aug 2012 00:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.416
X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lV25zGdiTeTz for <>; Tue, 14 Aug 2012 00:12:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 117EE11E8098 for <>; Tue, 14 Aug 2012 00:12:22 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id q7E7CKNk013629 for <>; Tue, 14 Aug 2012 10:12:20 +0300
X-CheckPoint: {5029F727-2-1B221DC2-4FFFF}
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 14 Aug 2012 10:12:19 +0300
Received: from ([]) by ([]) with mapi; Tue, 14 Aug 2012 10:12:18 +0300
From: Yoav Nir <>
To: IETF WebSec WG <>
Date: Tue, 14 Aug 2012 10:12:16 +0300
Thread-Topic: [websec] handling STS header field extendability
Thread-Index: Ac150zNRb1fEkDa/QvKTxfcyQGLsmAAF/5Iw
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11ec05d72c59a1cf2304c449eccd3ecd4ad377d26a
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-KSE-AntiSpam-Interceptor-Info: protection disabled
Subject: Re: [websec] handling STS header field extendability
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Aug 2012 07:12:24 -0000


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.



From: [] 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.