Re: [websec] handling STS header field extendability

Tobias Gondrom <> Sun, 19 August 2012 08:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C84DE21F848F for <>; Sun, 19 Aug 2012 01:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -96.667
X-Spam-Status: No, score=-96.667 tagged_above=-999 required=5 tests=[AWL=-1.305, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tTACsBW-hUwN for <>; Sun, 19 Aug 2012 01:23:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A414D21F848A for <>; Sun, 19 Aug 2012 01:23:10 -0700 (PDT)
Received: (qmail 17429 invoked from network); 19 Aug 2012 10:23:06 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2012 10:23:05 +0200
Message-ID: <>
Date: Sun, 19 Aug 2012 09:23:05 +0100
From: Tobias Gondrom <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Sun, 19 Aug 2012 08:23:12 -0000

On 19/08/12 01:56, Barry Leiba wrote:
>>>> I'd also noted that we need to decide on a IANA policy to declare.
>>> Do we need to do this?  Assuming the proposed resolution achieves
>>> consensus (and there have been no nays yet), we're not setting up a
>>> registry. I don't think we get to set a policy for a registry we're not
>>> setting up.
>> <hat="WG chair">
>> AFAIK from an administrative perspective, Yoav is right.
>> In general we set the IANA policy for registry updates at creation of the
>> registry. So no need to do it here without the registry (assuming we don't
>> create an IANA registry).
> The point in this case is that this is a response to Ben's GenART
> review, which suggested that we at least nail down the registration
> policy at this point, lest someone come along later with an extension
> and create the registry with, say, an FCFS policy (probably too
> light), or perhaps with a Standards Action policy (arguably too
> heavy).
> The WG can validly disagree with Ben's review, and unless Russ (or
> another AD) strongly agrees and uses it as a DISCUSS point, we're
> done.  Even in that case, the WG can still argue against it and try to
> convince the AD that it's OK not to do this... and, as Tobias point
> out, we usually don't.
Thanks for the clarification.
> So maybe we should modify what Jeff said, thus:
>>>> I'd also noted that we need to decide on a IANA policy to declare.
> "We need to decide on an IANA policy *or* explicitly decide that we
> don't want to choose that now, and leave it to whoever creates the
> registry later."
> Apparently, we have at least two votes for the latter, from Yoav and Tobias.
> Barry (with AD hat off, but handily tucked at the ready under his arm)

Yes, I would vote not to specify an IANA policy for a registry we don't define here. I would be in favor of leaving that to when or if we create such a registry later. Though I don't have a strong opinion on this.