Re: [websec] handling STS header field extendability

Barry Leiba <> Sun, 19 August 2012 00:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 867A321F84C9 for <>; Sat, 18 Aug 2012 17:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.01
X-Spam-Status: No, score=-103.01 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Oi9HrLBc1bQT for <>; Sat, 18 Aug 2012 17:56:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AAB1021F847C for <>; Sat, 18 Aug 2012 17:56:03 -0700 (PDT)
Received: by lahm15 with SMTP id m15so2846585lah.31 for <>; Sat, 18 Aug 2012 17:56:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=eZLntToehUNiDT+MAYF7Cj+5r1mka3VX+aXjSBM6aBc=; b=d/MPqZSzSmqtjjmpL+j99fY7E8NhAec429Wv2ABcjciSnQlasZri2rgeDabHA38G34 egSZyIjj1LOfqWS14/wcEZo5RW5+QMHWavXmudOREHoFEd0UYu4874Zdc6Zk53jy9Piq XvPj4YYSXMN2bxX62npQscJAB/Tf61WYDvJ8wNR+tnz4bRtKPXq+bHQbUfIZz3cYdsJI /F8fV1BmaAdqxk6jbgg/o+MED8lkUoq/xsU2AagSXYH7ZZQm7O1UXLpbPFHfsGvpvVCN xpnwD4W2BbU6fX81k1amyVGXHiodseQt+Bhra+dGmY9LP3trplTfYYitUvTSpTNxbkWV 0sMQ==
MIME-Version: 1.0
Received: by with SMTP id it10mr9325907lab.36.1345337762601; Sat, 18 Aug 2012 17:56:02 -0700 (PDT)
Received: by with HTTP; Sat, 18 Aug 2012 17:56:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Sat, 18 Aug 2012 20:56:02 -0400
X-Google-Sender-Auth: rbARc7XNWSGt8otYgxSVgmToUmg
Message-ID: <>
From: Barry Leiba <>
To: Tobias Gondrom <>
Content-Type: text/plain; charset=ISO-8859-1
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 00:56:04 -0000

>>> 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

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.

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)