Subject: Re: [kitten] OAUTH/SASL and the format debate

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 May 2012 15:53:53 +0200

William Mills <[email-masked]> writes:

> Having inquired of a number of folks that have implemented the XOAUTH
> mechanism and getting no reply, I'm planning to go with "silence ==
> consent" and presume there's no big objection to moving away form the
> HTTP format style for the SASL messages.  I' planning on a key/value
> pair format, which is easily extensible.  My plan was something like:

Great.  I like a key=value approach.  To me, it is better than JSON
since it is easier to parse when you don't have external libraries
available.

>     NONZERO ::=  %x31-39
>     key ::= NONZERO *DIGIT 
>     value ::= *(SP HTAB VCHAR)
>
>     msg_line ::= key SP value CRLF
>     sasl_msg ::= +msg_line CRLF
>
> We would need an IANA registry for keys.  Objections?  Other preferred
> formats?

Why digits as keys?  Some consistency with RFC 5801/RFC5802 would be
nice, so how about something like the following, in pseudo ABNF/regexp
language:

   key = [A-Za-z0-9_-]+
   value = [^,]*
   kvpair = key "=" value
   msg = kvpair ("," kvpair)*

This allows descriptive names for the "key" names.

/Simon

---

From: William Mills <[email-masked]>
Date: Tue, 15 May 2012 09:00:08 -0700 (PDT)

>________________________________
> From: Simon Josefsson <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, May 15, 2012 6:53 AM
>Subject: Re: OAUTH/SASL and the format debate
> 

Descriptive key names I like.  "=" instead of "SP" is fine too.  Comma separated means that the authorization header value will have to be base64 encoded, and I'm not sure I'm a big fan of that.  CRLF won't appear in the auth header.

Re-using the parser from 5801/5802 is attractive though.  Not sure what I prefer there.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 May 2012 18:33:30 +0200

William Mills <[email-masked]> writes:

> Descriptive key names I like.  "=" instead of "SP" is fine too.  Comma
> separated means that the authorization header value will have to be
> base64 encoded, and I'm not sure I'm a big fan of that.  CRLF won't
> appear in the auth header.
>

Is there some other character that isn't used in authorization headers
that could be used as a separator?

I also dislike having to base64 encode values if it can be avoided.
Another option is to escape "," but escaping is often troublesome as
well.

What I don't like about CRLF is that in some environments you may end up
combatting EOL conversions.  Also, doesn't some HTTP header allow
embedded CRLF as whitespace?

Another approach is to use ASCII NUL as separator.  The length is
implicit anyway, since you know when to stop parse.  That is:

key = [A-Za-z0-9_-]+
value = [^\00]*
kvpair = key "=" value
msg = kvpair (%x00 kvpair)*

This has the following properties:

* Easy to parse
* All non-NUL data values can be expressed (binary data with embedded
  NULs will have to be base64 encoded)
* No escaping
* You can use strlen and friends to find the end of the string to parse

/Simon

---

From: William Mills <[email-masked]>
Date: Tue, 15 May 2012 10:07:03 -0700 (PDT)

Inline...

>Sent: Tuesday, May 15, 2012 9:33 AM

I don't believe so, but there can be line continuations, that is escaped CRLF.  I was going to specifically disallow that in the syntax.

>* You can use strlen and friends to find the end of the string to parse

I'm not rabidly against NULL, though it makes life harder for the producer of the string to have to embed nulls and it's more annoying in other languages than C variants.  C variants can easily replace some other fencepost with NULL for in place string handling.  Agreed that EOL conversion is a PITA.  If it's not CRLF I would be more inclined to pick a control character like control-A or control-C (which has the tag EOT in ascii and so is weirdly pleasing).

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 15 May 2012 20:22:24 +0200

William Mills <[email-masked]> writes:

> I'm not rabidly against NULL, though it makes life harder for the
> producer of the string to have to embed nulls and it's more annoying
> in other languages than C variants.  C variants can easily replace
> some other fencepost with NULL for in place string handling.  Agreed
> that EOL conversion is a PITA.  If it's not CRLF I would be more
> inclined to pick a control character like control-A or control-C
> (which has the tag EOT in ascii and so is weirdly pleasing).

We are firmly in bikeshedding land here, but what about TAB as the
separator?

/Simon

---

From: Russ Allbery <[email-masked]>
Date: Tue, 15 May 2012 14:34:05 -0700

>> producer of the string to have to embed nulls and it's more annoying in
>> other languages than C variants.  C variants can easily replace some
>> other fencepost with NULL for in place string handling.  Agreed that
>> EOL conversion is a PITA.  If it's not CRLF I would be more inclined to
>> pick a control character like control-A or control-C (which has the tag
>> EOT in ascii and so is weirdly pleasing).

> We are firmly in bikeshedding land here, but what about TAB as the

While admittedly this is a wire protocol, I still think it's a bad idea to
assume that TAB will survive unmolested.  All it takes is editing test
data in a "helpful" editor and now your TAB is some number of spaces and
you have a confusing and strange problem that you're probably going to
waste some time on.

If we go that round, I think we'd be better off with some control
character that editors are unlikely to assign special properties to, like
Ctrl-A, Ctrl-C, or Ctrl-G.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 16 May 2012 16:17:34 +0100

On 15/05/2012 18:07, William Mills wrote:
>> From: Simon Josefsson<[email-masked]>
>> To: William Mills<[email-masked]>
>> Cc: "[email-masked]"<[email-masked]>
>> William Mills<[email-masked]>  writes:
>>
Right.
> I'm not rabidly against NULL, though it makes life harder for the producer of the string to have to embed nulls and it's more annoying in other languages than C variants.  C variants can easily replace some other fencepost with NULL for in place string handling.  Agreed that EOL conversion is a PITA.  If it's not CRLF
I don't think CRLF is particularly problematic. Using just LF is fine as 
well.
> I would be more inclined to pick a control character like control-A or control-C (which has the tag EOT in ascii and so is weirdly pleasing).
This is indeed a minor issue, but using a character that would be hard 
to type in telnet (such as NUL) would make debugging more difficult.

---

From: William Mills <[email-masked]>
Date: Fri, 18 May 2012 21:33:27 -0700 (PDT)

Well, I've got a draft done, however it's not playing nice with the submission tool, even though it passes all of the xml2rfc tools I checked.  

-bill

----- Original Message -----
> Sent: Tuesday, May 15, 2012 11:22 AM

---

From: William Mills <[email-masked]>
Date: Fri, 18 May 2012 22:00:19 -0700 (PDT)

Ah hah!  Eager readers can see the txt or PDF version at https://datatracker.ietf.org/submit/status/41447/

----- Original Message -----
> From: William Mills <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: 
> Sent: Friday, May 18, 2012 9:33 PM
> Subject: [kitten] New draft soon Re: OAUTH/SASL and the format debate
> 
> Well, I've got a draft done, however it's not playing nice with the 
> submission tool, even though it passes all of the xml2rfc tools I checked.  
> 
> 
> -bill
> 
> 
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>