Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9

Julian Reschke <> Tue, 20 March 2012 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BAA021F85A1 for <>; Tue, 20 Mar 2012 09:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.402
X-Spam-Status: No, score=-104.402 tagged_above=-999 required=5 tests=[AWL=-1.803, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lad2ptmOIE82 for <>; Tue, 20 Mar 2012 09:01:13 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 336AC21F861C for <>; Tue, 20 Mar 2012 09:01:13 -0700 (PDT)
Received: (qmail invoked by alias); 20 Mar 2012 16:01:12 -0000
Received: from (EHLO []) [] by (mp034) with SMTP; 20 Mar 2012 17:01:12 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19b87E/RxJbj9aNE2I3r0Xo6n9kuyI3J88Qm8eIKQ 3EUFsEOsBGDqk9
Message-ID: <>
Date: Tue, 20 Mar 2012 17:01:11 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: SM <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Subject: Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9
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, 20 Mar 2012 16:01:14 -0000

On 2012-03-20 16:29, SM wrote:
> Hi Julian,
> At 02:35 19-03-2012, Julian Reschke wrote:
>> I'd like to point out that I still think my concerns over the
>> inconsistent use of quoted-string
>> (<>)
>> are valid and not addressed; and I think they should be before you go
>> to IETF LC.
> Wasn't a similar issue raised in another WG recently?
> ...

Indeed; in the context of the auth parameters in the OAuth Bearer 
authentication scheme.

There's a slight difference though, the Bearer spec defined new 
parameters for an HTTP header field that already exists 
(WWW-Authenticate), while STS is a completely new header field.

In the first case, it's a bug (that got fixed), in this case it's "just" 
a bad idea. Note that HTTPbis P2 has advice with respect to this:

"Many header fields use a format including (case-insensitively) named 
parameters (for instance, Content-Type, defined in Section 6.8 of 
[Part3]). Allowing both unquoted (token) and quoted (quoted-string) 
syntax for the parameter value enables recipients to use existing parser 
components. When allowing both forms, the meaning of a parameter value 
ought to be independent of the syntax used for it (for an example, see 
the notes on parameter handling for media types in Section 2.3 of 
[Part3])." -- 

Best regards, Julian