IETF Logo Mail Archive

[websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux)

=JeffH <Jeff.Hodges@KingsMountain.com> Sat, 14 January 2012 00:24 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A4D1F0C46 for <websec@ietfa.amsl.com>; Fri, 13 Jan 2012 16:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.815
X-Spam-Level:
X-Spam-Status: No, score=-99.815 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_41=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a67Sv-t58ycV for <websec@ietfa.amsl.com>; Fri, 13 Jan 2012 16:24:07 -0800 (PST)
Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id E69301F0C48 for <websec@ietf.org>; Fri, 13 Jan 2012 16:24:06 -0800 (PST)
Received: (qmail 29180 invoked by uid 0); 14 Jan 2012 00:24:06 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 14 Jan 2012 00:24:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=/WgwH9ie7u0xEnp3gO23MjuZ0wnSQnFk/OAOIYxuXNU=; b=qVdGoHmoVD1FI/YbTR9wX8dlLyv5ytyuUYJpXdv3yExbSKX/qW6W9OjrFOe4tXpCt+TqiboH6WZapBsgQzoEiKSAPprgDGIAlwqLiVRAW1BBxIwVpvdju7u5cp7cox83;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.162]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1RlrPi-0008RW-87 for websec@ietf.org; Fri, 13 Jan 2012 17:24:06 -0700
Message-ID: <4F10CB26.2000206@KingsMountain.com>
Date: Fri, 13 Jan 2012 16:24:06 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: IETF WebSec WG <websec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jan 2012 00:24:07 -0000

In terms of this question of whether the STS header field directive ABNF should 
be..

1)  directive         = token [ "=" ( token | quoted-string ) ]

..or..

2)  directive         = token [ "=" token ]

..I can see both sides of the argument.

However, I've been thinking about it and grepping thru specs as well as firefox 
and chrome code, which has led me to think that from an overall (specification) 
consistency perspective, I'm leaning towards spec'g it with quoted-string in 
the ABNF (ie, as (1)). And has been pointed out in the discussion, it is sort 
of a moot point because the STS header field does not at this time make use of 
the quoted-string production, nor do we have on the table any extension 
directives that would do so.

In going through the FF and Chrome code, I note that both of their STS header 
field parsing methods appear to be special-case and AFAICT don't make use of 
other, more general HTTP header field parsing routines that are available in 
both implementations, and that are used to parse other HTTP response header 
fields. These latter more general HTTP header field parsing routines appear to 
be used for processing various of the other HTTP response and request header 
fields (and they appear to handle quoted-string). But it isn't clear why they 
aren't used for STS. It also isn't clear how uniformly these parsing routines 
are used for the panoply of HTTP header fields -- some other header fields 
appear to be special-cased as well (tho my c++ foo is wanting and the code is 
vast..). So yeah, it does seem messy.

=JeffH

v2.23.0 | Report a Bug | By Email