RE: iSCSI: BASE64 and numerical values

["Julian Satran" <Julian_Satran@il.ibm.com>]

And ignore completely the needs of some cryptographic protocols for large numerical values?  
I do not see why 6 bit values are more difficult to handle than 4 or 8 bit ones.

Julo

Robert Snively <rsnively@brocade.com> 05/21/2002 06:13 PM Please respond to Robert Snively

To:        "'Bill Studenmund'" <wrstuden@wasabisystems.com>, Julian Satran/Haifa/IBM@IBMIL         cc:        ips@ece.cmu.edu         Subject:        RE: iSCSI: BASE64 and numerical values

I have been having continuing problems understanding why
iSCSI is considering any use of base64, and I find myself
in total agreement with Bill's clear exposition of the
situation.

Upon reviewing RFC-2045, it is clear that base64 is a method
for containing handy binary values in a EMAIL structure that does
not use TCP/IP to transmit data, but rather uses obsolete
7-bit ASCII or (slightly less obsolete) EBCDIC strings to 
carry the data.  TCP/IP transmits data neutral octets, 
so binary values can be carried in their native binary 
string format (allowing for a possible requirement to pad
strings to an octet boundary).  The most standard way to
present those binary strings on a printer or as an input
value to a program is hexadecimal encoding.

For those reasons, I agree with Bill that we should delete
base64 from the text and use hexadecimal as he suggests.

Bob

> -----Original Message-----
> From: Bill Studenmund [mailto:wrstuden@wasabisystems.com]
> Sent: Monday, May 20, 2002 2:54 PM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: BASE64 and numerical values
> 
> 
> On Sat, 18 May 2002, Julian Satran wrote:
> 
> > Yes for regular numerical values it makes sense. We will 
> have to keep it
> > for large numerical values used for cryptography.  Julo
> 
> I realize I'm driving a semantic nit, but I don't think we should use
> BASE64 for any "numeric" values, only "binary" ones. I 
> believe we probably
> agree on what we want, I'm just worried that if the wording isn't 100%
> tight, the decode path can become a real mess (since we're 
> supposed to be
> liberal in what we accept :-).
> 
> I'd like to suggest we drop BASE64 from the text that 
> mentions numerical
> values. I really don't look forward to byteswapping a 256 or 512 bit
> number as part of BASE64 decode. :-)
> 
> I'd also like to suggest that for encoding large binary values using
> hexadecimal, we state that the hexadecimal representation is 
> that of the
> number in network byte order. i.e. if I have the five octets 
> 02 45 78 ab
> de, the hex constant is 0x024578abde. That makes the decode logic REAL
> easy; grab two hex characters & convert to one octet. Repeat 
> as needed.
> Please note that this is not the output you'd get with something like
> printf("0x%x", number) on a little-endian machine.
> 
> Thirdly, I'd like to suggest we drop decimal support from 
> binary objects.
> It too has the cumbersome byte-swapping issue that I started 
> this thread
> about, just in reverse. :-)
> 
> I realize that's a lot for one EMail. :-)
> 
> To try and be proactive about this, I'd like to suggest 
> revised text for
> section 4.1 (of course needs word-wrapping). For the definitions:
> 
>      hex-constant: hexadecimal constant encoded as a string start-
>        ing with "0x" or "0X" followed by 1 or more digits or the
>        letters a, b, c, d, e, f, A, B, C, D, E and F. Hex-constants
>        are used to encode numerical values or binary strings. When
>        used to encode numerical values the excessive use of leading
>        0 digits is discouraged. When used to encode binary strings
>        hexadecimal constants must have an even number of digits,
>        and have an implicit byte-length that
>        includes 4 bits for every hexadecimal digit of the constant,
>        including leading zeroes (i.e., a hex-constant of n hexadeci-
>        mal digits has a byte-length of n/2). Additionally, when used
>        to encode binary strings, hexadecimal constants shall be
>        expressed in network byte order (i.e., the octet stream 02
>        45 78 ab de would be expressed as "0x024578abde").
> 
>      decimal-constant: an unsigned decimal number - the digit 0 or a
>        string of 1 or more digits starting with a non-zero digit.
>        This encoding is not used for numerical values equal or
>        greater than 2**64.
> 
>      base64-constant: base64 constant encoded as a string starting
>        with "0b" or "0B" followed by 1 or more digits or letters or
>        plus or slash or equal. The encoding is done according to
>        [RFC2045]. base64-constants are used to encode binary strings.
>        Base64-constants have an implicit byte-length that includes 6
>        bits for every character of the constant excluding trailing
>        equals (i.e., a base64-constant of n base64 characters
>        excluding the trailing equals and m trailing equals has a
>        byte-length of ((the integer part of) ((n+3)*3/4) - m).
> 
>        regular-numerical-value :  an unsigned integer less than 2**64
>          encoded as a decimal-constant, or hex constant.
> 
>        large-numerical-value :  an unsigned integer larger than or
>          equal to 2**64 encoded as a hex constant.
> 
> [no change for numerical-value or numerical-range]
> 
>        binary-value :  a binary string encoded as a hex-con-
>          stant or base64-constant.  The length of the string is either
>          specified by the key definition or is implicit byte-length of
>          the encoded string.
> 
> [delete regualar-binary-value and large-binary-value since 
> the distinction
> is gone]
> 
> I don't see it explicitly mentioned anywhere, but I think all 
> of the CHAP
> (and SRP, but not sure) keys are large numericalal values, and the
> kerberos and SPKM keys are binary values.
> 
> Also, I think the CHAP keys need the field length features of 
> hexadecimal
> binary strings, but they are numbers, not binary strings. Not 
> sure how to
> word that.
> 
> Take care,
> 
> Bill
> 
>