Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt

Barry Leiba <> Tue, 30 December 2014 19:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9248B1A1B44; Tue, 30 Dec 2014 11:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fh7dvlPqUjVJ; Tue, 30 Dec 2014 11:48:24 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56E0D1A1B37; Tue, 30 Dec 2014 11:48:24 -0800 (PST)
Received: by with SMTP id ms9so12977315lab.10; Tue, 30 Dec 2014 11:48:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/uOaUyuYr8Slay8z+8vm0XBCu1Nt6ZOoYRY1F3BS8qk=; b=JGlH1vdZbhpcaSNuNKCWV4BakTAnedBZ1Jn4hn7awRmeUMjDb7eiX3kq0/mgqm9P+J /tc5gGzOX5EWlNHWweKgZWGXoDtTkRXRXQQX7WL/Tp8H55D8IgBWOZu4WnSS4a8b0dtL zsC5ofWTY1wEf/o+GhVaMHgSfbQf17SSsKRKsdmjIOYiLFld91UJyCS0UBT5bnNbnoLS L1XE2n/L4rlSZhItwd+xQ+Gy0IssaJIAehr76TBfVjAUyZ9YiztwtnglqgLvP40Ql98+ stnQjAgg+dTF/WnLVZShEk+xgBLEkhliyoo2KZ3Oo5Awire5dzx5HgGIA0PuT4DF+Amg K6jQ==
MIME-Version: 1.0
X-Received: by with SMTP id w1mr63290708lbb.68.1419968902631; Tue, 30 Dec 2014 11:48:22 -0800 (PST)
Received: by with HTTP; Tue, 30 Dec 2014 11:48:22 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 30 Dec 2014 14:48:22 -0500
X-Google-Sender-Auth: OX_LzL9K6tPFqoL1RNnXZUxzDcM
Message-ID: <>
From: Barry Leiba <>
To: Stephen Farrell <>
Content-Type: text/plain; charset=ISO-8859-1
Cc:, "" <>, "" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-httpauth-hoba-08.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Dec 2014 19:48:25 -0000

On just a couple of points...

>> Page 6/7/13, Figure 1/2/3: I'm not sure that something that is
>> entirely textural is best called a "Figure". But in any case, since
>> the text is, or at least has, lines that are flush left, it looks like
>> part of the preceding text and there isn't a clear demarcation of the
>> start. I recommend that the body of the Figures be indented 3 or 4
>> spaces.
> I'd prefer let the RFC editor fix those if needed.

I think that if we think a change in the formatting would make things
clearer, we should do that ourselves, and not defer it to the RFC
Editor.  *We* should be happy with the document before we send it

>> Page 19, IANA Considerations: It seems from
>> draft-leiba-coton-iana-5226bis that IANA would prefer IANA
>> Considerations to be written in the past tense as if the actions had
>> already been accomplished, presumably to minimize IANA re-writing
>> effort. Thus, I suggest that consideration be given to changing the
>> initial part, between the Section 9 heading and the Section 9.1
>> heading, to the following and making similar changes in the remainder
>> of the IANA Considerations Section:

I'm with Stephen here: please leave this alone.  At this point, the
document is making a request, and that's a fine way to put it.

>> Page 20, Section 9.4: Suggest the "Meaning" for 2 be "an unformatted
>> UTF8 string". There should probably be a Reference column. "a small
>> positive integer" is undefined.
> Oh come on. Small positive integer utterly clear as is unformatted
> string in this context. UTF8 isn't needed here as this is not meant
> to be seen by a user.

With this and all other strings, the question isn't whether users are
going to see it or not, but how implementors are supposed to know what
a "string" is and how to create it.  If it's an arbitrary sequence of
bytes, then it should say that, rather than "string".  If it's really
a string and is meant to represent characters in some encoding system,
then it needs to say either what encoding system that is (UTF-8,
US-ASCII, or whatever) or that it doesn't matter and that any encoding
can be used.  The latter only works if the string is never consumed by
an entity other than the one that created it.