I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This draft specifies an Experimental protocol to use digital
signatures in response to challenges for authentication to HTTP
servers as a replacement for passwords. There are a lot more details
than that and considerable effort has been put into making this fit
into existing web authentication so as to be easily deployable.
Overall, it looks like a good job. See comments below.

As a heavily security oriented draft, I recommend it be looked at by
the non-author Security AD :-)


> Security Comments <
---------------------

This draft is fairly clear about what happens when mandatory 2119
requirements are violated in strictly security contexts, such as a
signature not validating. But is generally doesn't say much about
what happens when mandatory formatting requirements are violated. I
guess if things don't parse, then authentication will fail. But, for
example, it says "The "realm" attribute MUST NOT appear more than
once." Whenever I see something like that, I say to myself, OK, so
what happens if the "MUST NOT" is violated? If the spec says nothing,
then I would expect that with some implementations authentication
would fail while others would use the first realm attribute and still
others would use the last realm attribute. Could that be a problem?

This draft uses "random" and "randomness" in various places without
any reference/definition.

Security Considerations:

Perhaps there should be a reference in the Security Considerations
section to Section 1.1.

Can some level of confusion/denial be caused by setting max-age to a
lower value than the server intended?

Appendix B: It is good that an example is provided it seems like some
things are missing. Shouldn't it specify the "alg" string and wouldn't
it be useful if it gave the TBS blob explicitly?

> Wording/Format Comments <
---------------------------

Abstract: I always worry about words like "all" (or, being recursive
to this sentence, "always" :-). I suggest deleting the one occurrence
of "all" in the Abstract.

Page 5, Section 1.2
OLD
   That will contain of at least one CPK and a web-origin;
                  ^^
NEW
   That will contain at least one CPK and a web-origin;

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.

Page 6, Section 2:
- For "alg" inconsistently says it is "an ASCII character" and "ASCII
numbers" where perhaps it should say "an ASCII encoded one or two digit
non-negative integer" or something.
- For "origin" perhaps the example should note that it would be
prefixed by "28:" in the TBS blob.
- Delete one of the two sequential occurrences of "reduce the amount
of".

Page 10, Section 5:
I suggest rewording this sentence:
OLD
   This section also
   covers the actions that give HOBA similar user features as today's
   passwords have.
NEW
   This section also
   covers the actions that give HOBA user features similar to today's
   passwords.

Page 16, Section 6.4: duplicated word "response".

Page 18, Section 8.2: Is it a good idea to mention a particular
on-line service name here?

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:

   IANA has created the registries and made the registration specified
   below, placing the new registries in a new "HTTP Origin-Bound
   Authentication (HOBA) Parameters" category.

Page 20, Section 9.3: A better way to note the restriction on
potential values of Algorithm Name would be to add a third entry to
the registry something like the following (there should also be a
third Reference column):

 2-99        Unassigned        [this document]

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.

Page 20, Section 9.5: Seems like this should say "UTF8 string" and I'm
not sure it needs "at the user's/UA's whim". There should also be a
"[this document]" entry in a Reference column.

Maybe there should be ABNF for "kid" and "did" somewhere. Since "kid"
and "did" are ordinary English words, suggest globally replacing them
with "KID" and "DID" respectively.

Page 24, Appendix A
This is a nice appendix but there is no reference to it anywhere in the
body of the draft. Suggest adding such a reference to the
Introduction.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 at gmail.com