Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

On 08/01/15 12:40, Stephen Farrell wrote:
> 
> (Richard and I plan to chat via IM before the call hopefully
> so this is more to tee that up than to clear right now.)

So we did that. There're a few more tweaks in [1,2] and
Richard has cleared (thanks Richard).

If folks could check I didn't mess up with edits, that'd
be good,
Ta,
S.


> 
> There are a couple of changes below, those are done in the
> working version at the usual [1,2].
> 
>    [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt
>    [2]
> https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt
> 
> On 08/01/15 12:06, Richard Barnes wrote:
>> On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell <[e-mail]>
>> wrote:
>>
>>>
>>> Hiya,
>>>
>>> On 08/01/15 10:23, Richard Barnes wrote:
>>>> Hey guys,
>>>>
>>>> Thanks for responding productively to a DISCUSS that I admit was not
>>>> written very politely.  Sorry about that.
>>>
>>> I do it myself from time to time, no probs. (And to be honest I
>>> was more rude about your ballot in IM to someone else, so we're
>>> even:-)
>>>
>>>>
>>>> Couple of comments inline.
>>>>
>>>> On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell <
>>> [e-mail]>
>>>> wrote:
>>>>
>>>>>
>>>>> FWIW, I'm fine that Paul's recollection of the WG stuff is better
>>>>> than mine and with his putting the pkcs#1 stuff in too.
>>>>>
>>>>> S
>>>>>
>>>>> On 08/01/15 01:19, Paul Hoffman wrote:
>>>>>> On Jan 7, 2015, at 4:20 PM, Richard Barnes <[e-mail]> wrote:
>>>>>>> (1) It does not seem to me that the mechanism defined in this document
>>>>>>> actually conforms to the framework for HTTP authentication.  The
>>> general
>>>>>>> framework defined in RFC 7235 is all scoped to a resource -- you can
>>>>>>> implement authorization for a specific resource, without impacting
>>>>>>> anything else on the server.  HOBA, by contrast, requires the
>>>>>>> authenticating resource to be also be correlated to several resource
>>>>>>> under .well-known, meaning that it will not be usable in a large
>>> number
>>>>>>> of deployment circumstances.  Was this issue discussed in the WG, and
>>>>> was
>>>>>>> there input from the broader HTTP community?
>>>>>>
>>>>>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating
>>>>> resource" in HOBA is purposely more expressive than that in RFC 7235,
>>> and
>>>>> thus takes more primitives than HTTP auth. There was plenty of WG
>>>>> discussion around this.
>>>>>
>>>>
>>>> If you happen to have a pointer to that discussion, it would help me feel
>>>> more comfortable.
>>>>
>>>> To be a little clearer about my concern, it seems like the fact that you
>>>> don't carry the public key in the Authorization header means that the
>>>> authenticating resource has to be tied to the .well-known/hoba/register/
>>>> resource.
>>>
>>> Yes, that's true. But entirely acceptable as a reasonable
>>> limitation of the scheme. It's reasonable because a) less
>>> header bloat if you send public key once, b) with RSA in
>>> particular public keys are big, and c) I hold out the hope
>>> that I can someday develop a privacy friendly kid type so
>>> that the strongly identifying nature of the HOBA signature
>>> is addressed. (I have not so far figured one out, sadly.)
>>>
>>> So I still don't see a reason for this to block the experiment.
>>>
>>>>
>>>>
>>>>
>>>>>>> (2) What is your justification for using a SHA-1 based signature in a
>>>>> new
>>>>>>> protocol, when it is being actively deprecated elsewhere, in
>>> particular
>>>>>>> the web PKI?
>>>>>>
>>>>>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a
>>>>> MAY-level definition when there is a more popular algorithm
>>> (RSA-SHA256) at
>>>>> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no
>>> danger
>>>>> to having it here.
>>>>>
>>>>
>>>> But if you're REQUIRED to support RSA-SHA256, why would you ever use
>>>> RSA-SHA1?
>>>>
>>>> Color me pretty skeptical that there are implementations that can't
>>> support
>>>> SHA-2 nowadays.  I just saw a presentation yesterday about an IoT crypto
>>>> libary that fits within 64K and supports SHA-256 along with a bunch of
>>>> other algorithms.
>>>
>>> That was the case with PHP when this work started and at that time I
>>> needed the rsa-sha1 code point for my code. That was only a year or
>>> two ago. I bet there are still web sites with only that version of
>>> PHP available today - that is scary but adding HOBA to such could
>>> still represent a security improvement if it meant that a new
>>> application can be deployed without a new password verifier DB, and
>>> that would be the case since we have the rsa-sha1 codepoint. Taking
>>> away the codepoint would prevent such being deployed. And we know
>>> for sure that the relevant risk here is not the signature crypto
>>> but is overwhelmingly and utterly the password verifier DB. You are
>>> I fear arguing that we ought prioritise crypto plumbing over the
>>> real security risk.
>>>
>>> I have not done a survey of all web development platforms to check
>>> if this is now a solved issue or not. You skepticism is fine (and
>>> perhaps correct) but if you don't do that survey, then blocking on
>>> that basis is not correct.
>>>
>>
>> Isn't the burden on the one trying to weaken the protocol?  :)
>>
>> All of the web development platforms I can think of have SHA-2 support.
>> Looking at the list on wikipedia:
>> http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites
>>
>> ASP.NET, C, C++, Java, JavaScript, Perl, Python, Ruby: Should be obvious
>> PHP, Xhp, Hack: http://php.net/manual/en/function.hash.php
>> Scala: https://github.com/Nycto/Hasher
>> Go: http://golang.org/pkg/crypto/sha256/
>> Erlang: http://erlang.org/doc/man/crypto.html
>> D: http://dlang.org/phobos/std_digest_sha.html
>>
>> So unless you can come up with a platform that *doesn't* support SHA-2, I
>> don't see why it should be allowed.
>>
>> In any event, it seems like this whole pageant is moot, since the document
>> *requires* SHA-2 support.  If you've got that, why would you ever do
>> SHA-1?
> 
> Because e.g. PHP4 is still installed on a site where I don't
> get to fix that. Shodanhq indicates there are a number of those
> still about, though less than I'd have expected, but not sure
> if they search for that deliberately or as a side-effect.
> 
> But anyway, I have no problem saying rsa-sha1 MUST NOT be used
> except in cases like that where you have no choice.
> 
> Given that the codepoint was in the draft for quite a while,
> it seems silly (process-wonkery?:-) to take it out now and
> then maybe re-use it for something else later, so I'd argue
> we can leave the code point.
> 
> So I added:
> 
> "RSA-SHA1 MUST
> NOT be used, except in cases where SHA256 is unavailable, say
> if some developmemt platform has to be used that is quite out
> of date."
> 
> Happy to wordsmith that.
> 
> 
>>
>>
>>
>>>>>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." ->
>>> MUST
>>>>>>
>>>>>> There is no interoperability mandate for particular RSA key lengths, so
>>>>> "SHOULD" is more appropriate here (until the IESG finally gets around to
>>>>> updating RFC 2119...).
>>>>>
>>>>
>>>> This is not about interop, it's about achieving an appropriate security
>>>> level.  That is another thing for which MUSTs are commonly used.
>>>>
>>>> (If we're going to talk about 2119, the phrasing is "absolute requirement
>>>> of the specification", not "absolutely required for interop".)
>>>>
>>>> To Stephen's point on JS performance: I made a little empirical test:
>>>> http://www.ipv.sx/tmp/rsa-2048.html
>>>>
>>>> On a good laptop, a good phone, and a crappier phone, the time to
>>> generate
>>>> a 2048-bit key is roughly (choosing representative values after a few
>>>> clicks):
>>>> MacBook Pro: 5340ms
>>>> iPhone 6: 7192ms
>>>> FirefoxOS Flame: 31084ms
>>>
>>> I've seen it take >120s which is not usable in this context. That
>>> was on older iphones (4 I think) with various browsers. With some
>>> older versions of IE on older laptops it's also horrendous.
>>>
>>>> These values are not great, but they're within the range of asynchronous
>>>> operations that web pages already have to deal with, especially given
>>> that
>>>> keygen is a once-per-origin operation.  As far as sign() operations, the
>>>> worst case among these devices was ~500ms, which is again not terrible.
>>>
>>> Signing is tolerable in most cases thanks to the getchal and using
>>> a worker.
>>>
>>> And the appropriate security level for HOBA is not the usual thing
>>> actually. Here we're after "substantially better than passwords"
>>> and will likely transition to a cookie (bearer token) just after
>>> signing. So I would argue that even an otherwise-undesirable 1500
>>> bit modulus could be ok here, if a site has a way to bump that up
>>> later, e.g. as new browsers deploy webcrypto. However, that is not
>>> stuff that needs or ought be in the RFC.
>>>
>>> For an experimental RFC we should not block on this. (I would myself
>>> for a stds track but not exp.)
>>>
>>
>> Yeah, OK.  I guess I can live with this.  Could we possibly add some
>> bounding text, e.g.,
>>
>> "Keys shorter than 2048 bits should only be used in cases where generating
>> 2048-bit (or longer) keys is impractical, e.g., on constrained devices.  If
>> an application uses short keys, then it MUST expire and re-generate keys
>> periodically, say every few weeks."
> 
> I've added the first sentence. I don't think the 2nd is wise
> really but will explain in IM as its a bit convoluted. (And
> of course, HOBA itself has no concept of expiry at all, that's
> for the account handling code.)
> 
> Cheers,
> S.
> 
>>
>>
>>
>>
>>>>>>> (4) Given that the size of the header seems to be a concern (since
>>>>> you're
>>>>>>> not passing the key in the header), why are there no ECC signing
>>>>>>> algorithms defined?  It seems like if you used any of the normal
>>> curves,
>>>>>>> you could comfortably pass the key along with the authentication
>>> value.
>>>>>>
>>>>>> Because there is not yet agreement on which ECC signing algorithms are
>>>>> likely to be popular in a year or two. We're watching the CFRG
>>> discussion,
>>>>> and it is not yet coming to consensus. When it does, this Experimental
>>> RFC
>>>>> can be updated.
>>>>>
>>>>
>>>> This is pretty weak sauce.  It's not like ECDSA with P-256 is going to go
>>>> away overnight when CFRG make up their minds.
>>>
>>> The development platform issue that perhaps no longer exists for
>>> sha256 is I believe still real for ecdsa.
>>>
>>> But the main thing I'd like from the CFRG work would be to lose the
>>> RNG requirement at signing time, which is unnecessarily a part of
>>> ECDSA. That's a real security win, if we get it.
>>>
>>>> Maybe I'm overly worried about the complexity here, but it seems like
>>> using
>>>> ECC could allow you to just shove the public key in the Authorization
>>>> header.  That would obviate the need for the registration resource,
>>>> resolving point 1 above, and generally make HOBA easier to implement.
>>>>
>>>> Nonetheless, I moved this point to a COMMENT.
>>>>
>>>>
>>>>>> (5) For that matter, why bother defining a new algorithm registry at
>>> all,
>>>>>>> when JWA provides a perfectly nice one that only costs you 4
>>> characters.
>>>>>>
>>>>>> We did not want to be tied to the JWA registry, given that JOSE could
>>> go
>>>>> in quite different directions.
>>>>>
>>>>
>>>> Fair enough.  Cleared this one.
>>>
>>> Cool.
>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> COMMENT:
>>>>>>> ----------------------------------------------------------------------
>>>>>>>
>>>>>>> The HOBA-TBS construction seems really unnecessarily complicated.
>>> Other
>>>>>>> than in the "origin" component, there are no ":" characters allowed in
>>>>>>> any of the components, so if you could remove the unnecessarily pretty
>>>>>>> serialization of the origin, you could just use ':' as a delimiter.
>>> Or
>>>>>>> leave the origin, and delimit with something like %x20.  Either way,
>>>>> this
>>>>>>> length construction seems like a pain to implement by comparison.
>>>>>>
>>>>>> We started with a less complex construction, and the WG specifically
>>>>> asked for this.
>>>>>>
>>>>>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point
>>>>> spaces
>>>>>>> unnecessarily.
>>>>>>
>>>>>> It is also unwise to have more than 99 possible algorithms for signing.
>>>>>
>>>>
>>>> Sure, but that seems like a process issue, not one to enshrine in syntax.
>>>
>>> The opposite I think. We seem unable to fix the vanity/national crypto
>>> thing via process so I'd like to see us try via syntax myself. But
>>> that's for another day:-)
>>>
>>> Cheers,
>>> S.
>>>
>>>>
>>>>
>>>>
>>>>>>> In addition to the funny title of Section 6.2.2, the contents seem
>>> kind
>>>>>>> of risible as well.  Making a OTP is 100% equivalent to the mechanism
>>>>>>> recommended in Section 6.2.3, and arguably more likely to deploy
>>> (since
>>>>>>> the OTP doesn't have special semantics of being a URI).
>>>>>>
>>>>>> There is wide disagreement on what is more likely to deploy. Also, I'm
>>>>> pretty sure Stephen is correct about your view on OTP here.
>>>>>>
>>>>>>> Please update the algorithms so that the reader doesn't have to go
>>> look
>>>>>>> up which algorithm this is (PKCS1 vs. PSS).
>>>>>>>
>>>>>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]"
>>>>>>>
>>>>>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of
>>>>>>> [RFC3447]"
>>>>>>
>>>>>> Sounds good; now fixed in the post-IESG version.
>>>>>>
>>>>>>> Given how convoluted the use case is here, an example would be very
>>>>>>> helpful.  At the very least to demonstrate the syntax of the
>>>>>>> WWW-Authenticate header.
>>>>>>
>>>>>> This doesn't seem all that needed, regardless of your view of
>>>>> convolution.
>>>>>>
>>>>>> --Paul Hoffman
>>>>>> _______________________________________________
>>>>>> http-auth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/http-auth
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell <[e-mail]>
>> wrote:
>>
>>>
>>> Hiya,
>>>
>>> On 08/01/15 10:23, Richard Barnes wrote:
>>>> Hey guys,
>>>>
>>>> Thanks for responding productively to a DISCUSS that I admit was not
>>>> written very politely.  Sorry about that.
>>>
>>> I do it myself from time to time, no probs. (And to be honest I
>>> was more rude about your ballot in IM to someone else, so we're
>>> even:-)
>>>
>>>>
>>>> Couple of comments inline.
>>>>
>>>> On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell <
>>> [e-mail]>
>>>> wrote:
>>>>
>>>>>
>>>>> FWIW, I'm fine that Paul's recollection of the WG stuff is better
>>>>> than mine and with his putting the pkcs#1 stuff in too.
>>>>>
>>>>> S
>>>>>
>>>>> On 08/01/15 01:19, Paul Hoffman wrote:
>>>>>> On Jan 7, 2015, at 4:20 PM, Richard Barnes <[e-mail]> wrote:
>>>>>>> (1) It does not seem to me that the mechanism defined in this document
>>>>>>> actually conforms to the framework for HTTP authentication.  The
>>> general
>>>>>>> framework defined in RFC 7235 is all scoped to a resource -- you can
>>>>>>> implement authorization for a specific resource, without impacting
>>>>>>> anything else on the server.  HOBA, by contrast, requires the
>>>>>>> authenticating resource to be also be correlated to several resource
>>>>>>> under .well-known, meaning that it will not be usable in a large
>>> number
>>>>>>> of deployment circumstances.  Was this issue discussed in the WG, and
>>>>> was
>>>>>>> there input from the broader HTTP community?
>>>>>>
>>>>>> Yes and yes. (Stephen is wrong that it was not.) The "authenticating
>>>>> resource" in HOBA is purposely more expressive than that in RFC 7235,
>>> and
>>>>> thus takes more primitives than HTTP auth. There was plenty of WG
>>>>> discussion around this.
>>>>>
>>>>
>>>> If you happen to have a pointer to that discussion, it would help me feel
>>>> more comfortable.
>>>>
>>>> To be a little clearer about my concern, it seems like the fact that you
>>>> don't carry the public key in the Authorization header means that the
>>>> authenticating resource has to be tied to the .well-known/hoba/register/
>>>> resource.
>>>
>>> Yes, that's true. But entirely acceptable as a reasonable
>>> limitation of the scheme. It's reasonable because a) less
>>> header bloat if you send public key once, b) with RSA in
>>> particular public keys are big, and c) I hold out the hope
>>> that I can someday develop a privacy friendly kid type so
>>> that the strongly identifying nature of the HOBA signature
>>> is addressed. (I have not so far figured one out, sadly.)
>>>
>>> So I still don't see a reason for this to block the experiment.
>>>
>>>>
>>>>
>>>>
>>>>>>> (2) What is your justification for using a SHA-1 based signature in a
>>>>> new
>>>>>>> protocol, when it is being actively deprecated elsewhere, in
>>> particular
>>>>>>> the web PKI?
>>>>>>
>>>>>> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a
>>>>> MAY-level definition when there is a more popular algorithm
>>> (RSA-SHA256) at
>>>>> MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no
>>> danger
>>>>> to having it here.
>>>>>
>>>>
>>>> But if you're REQUIRED to support RSA-SHA256, why would you ever use
>>>> RSA-SHA1?
>>>>
>>>> Color me pretty skeptical that there are implementations that can't
>>> support
>>>> SHA-2 nowadays.  I just saw a presentation yesterday about an IoT crypto
>>>> libary that fits within 64K and supports SHA-256 along with a bunch of
>>>> other algorithms.
>>>
>>> That was the case with PHP when this work started and at that time I
>>> needed the rsa-sha1 code point for my code. That was only a year or
>>> two ago. I bet there are still web sites with only that version of
>>> PHP available today - that is scary but adding HOBA to such could
>>> still represent a security improvement if it meant that a new
>>> application can be deployed without a new password verifier DB, and
>>> that would be the case since we have the rsa-sha1 codepoint. Taking
>>> away the codepoint would prevent such being deployed. And we know
>>> for sure that the relevant risk here is not the signature crypto
>>> but is overwhelmingly and utterly the password verifier DB. You are
>>> I fear arguing that we ought prioritise crypto plumbing over the
>>> real security risk.
>>>
>>> I have not done a survey of all web development platforms to check
>>> if this is now a solved issue or not. You skepticism is fine (and
>>> perhaps correct) but if you don't do that survey, then blocking on
>>> that basis is not correct.
>>>
>>>>>>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." ->
>>> MUST
>>>>>>
>>>>>> There is no interoperability mandate for particular RSA key lengths, so
>>>>> "SHOULD" is more appropriate here (until the IESG finally gets around to
>>>>> updating RFC 2119...).
>>>>>
>>>>
>>>> This is not about interop, it's about achieving an appropriate security
>>>> level.  That is another thing for which MUSTs are commonly used.
>>>>
>>>> (If we're going to talk about 2119, the phrasing is "absolute requirement
>>>> of the specification", not "absolutely required for interop".)
>>>>
>>>> To Stephen's point on JS performance: I made a little empirical test:
>>>> http://www.ipv.sx/tmp/rsa-2048.html
>>>>
>>>> On a good laptop, a good phone, and a crappier phone, the time to
>>> generate
>>>> a 2048-bit key is roughly (choosing representative values after a few
>>>> clicks):
>>>> MacBook Pro: 5340ms
>>>> iPhone 6: 7192ms
>>>> FirefoxOS Flame: 31084ms
>>>
>>> I've seen it take >120s which is not usable in this context. That
>>> was on older iphones (4 I think) with various browsers. With some
>>> older versions of IE on older laptops it's also horrendous.
>>>
>>>> These values are not great, but they're within the range of asynchronous
>>>> operations that web pages already have to deal with, especially given
>>> that
>>>> keygen is a once-per-origin operation.  As far as sign() operations, the
>>>> worst case among these devices was ~500ms, which is again not terrible.
>>>
>>> Signing is tolerable in most cases thanks to the getchal and using
>>> a worker.
>>>
>>> And the appropriate security level for HOBA is not the usual thing
>>> actually. Here we're after "substantially better than passwords"
>>> and will likely transition to a cookie (bearer token) just after
>>> signing. So I would argue that even an otherwise-undesirable 1500
>>> bit modulus could be ok here, if a site has a way to bump that up
>>> later, e.g. as new browsers deploy webcrypto. However, that is not
>>> stuff that needs or ought be in the RFC.
>>>
>>> For an experimental RFC we should not block on this. (I would myself
>>> for a stds track but not exp.)
>>>
>>>>>>> (4) Given that the size of the header seems to be a concern (since
>>>>> you're
>>>>>>> not passing the key in the header), why are there no ECC signing
>>>>>>> algorithms defined?  It seems like if you used any of the normal
>>> curves,
>>>>>>> you could comfortably pass the key along with the authentication
>>> value.
>>>>>>
>>>>>> Because there is not yet agreement on which ECC signing algorithms are
>>>>> likely to be popular in a year or two. We're watching the CFRG
>>> discussion,
>>>>> and it is not yet coming to consensus. When it does, this Experimental
>>> RFC
>>>>> can be updated.
>>>>>
>>>>
>>>> This is pretty weak sauce.  It's not like ECDSA with P-256 is going to go
>>>> away overnight when CFRG make up their minds.
>>>
>>> The development platform issue that perhaps no longer exists for
>>> sha256 is I believe still real for ecdsa.
>>>
>>> But the main thing I'd like from the CFRG work would be to lose the
>>> RNG requirement at signing time, which is unnecessarily a part of
>>> ECDSA. That's a real security win, if we get it.
>>>
>>>> Maybe I'm overly worried about the complexity here, but it seems like
>>> using
>>>> ECC could allow you to just shove the public key in the Authorization
>>>> header.  That would obviate the need for the registration resource,
>>>> resolving point 1 above, and generally make HOBA easier to implement.
>>>>
>>>> Nonetheless, I moved this point to a COMMENT.
>>>>
>>>>
>>>>>> (5) For that matter, why bother defining a new algorithm registry at
>>> all,
>>>>>>> when JWA provides a perfectly nice one that only costs you 4
>>> characters.
>>>>>>
>>>>>> We did not want to be tied to the JWA registry, given that JOSE could
>>> go
>>>>> in quite different directions.
>>>>>
>>>>
>>>> Fair enough.  Cleared this one.
>>>
>>> Cool.
>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> COMMENT:
>>>>>>> ----------------------------------------------------------------------
>>>>>>>
>>>>>>> The HOBA-TBS construction seems really unnecessarily complicated.
>>> Other
>>>>>>> than in the "origin" component, there are no ":" characters allowed in
>>>>>>> any of the components, so if you could remove the unnecessarily pretty
>>>>>>> serialization of the origin, you could just use ':' as a delimiter.
>>> Or
>>>>>>> leave the origin, and delimit with something like %x20.  Either way,
>>>>> this
>>>>>>> length construction seems like a pain to implement by comparison.
>>>>>>
>>>>>> We started with a less complex construction, and the WG specifically
>>>>> asked for this.
>>>>>>
>>>>>>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point
>>>>> spaces
>>>>>>> unnecessarily.
>>>>>>
>>>>>> It is also unwise to have more than 99 possible algorithms for signing.
>>>>>
>>>>
>>>> Sure, but that seems like a process issue, not one to enshrine in syntax.
>>>
>>> The opposite I think. We seem unable to fix the vanity/national crypto
>>> thing via process so I'd like to see us try via syntax myself. But
>>> that's for another day:-)
>>>
>>> Cheers,
>>> S.
>>>
>>>>
>>>>
>>>>
>>>>>>> In addition to the funny title of Section 6.2.2, the contents seem
>>> kind
>>>>>>> of risible as well.  Making a OTP is 100% equivalent to the mechanism
>>>>>>> recommended in Section 6.2.3, and arguably more likely to deploy
>>> (since
>>>>>>> the OTP doesn't have special semantics of being a URI).
>>>>>>
>>>>>> There is wide disagreement on what is more likely to deploy. Also, I'm
>>>>> pretty sure Stephen is correct about your view on OTP here.
>>>>>>
>>>>>>> Please update the algorithms so that the reader doesn't have to go
>>> look
>>>>>>> up which algorithm this is (PKCS1 vs. PSS).
>>>>>>>
>>>>>>> OLD: "RSA is defined in Section 8.2 of [RFC3447]"
>>>>>>>
>>>>>>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of
>>>>>>> [RFC3447]"
>>>>>>
>>>>>> Sounds good; now fixed in the post-IESG version.
>>>>>>
>>>>>>> Given how convoluted the use case is here, an example would be very
>>>>>>> helpful.  At the very least to demonstrate the syntax of the
>>>>>>> WWW-Authenticate header.
>>>>>>
>>>>>> This doesn't seem all that needed, regardless of your view of
>>>>> convolution.
>>>>>>
>>>>>> --Paul Hoffman
>>>>>> _______________________________________________
>>>>>> http-auth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/http-auth
>>>>>>
>>>>>
>>>>
>>>
>>
>