Re: Section 4.1 clarifications

[Mark Bakke <mbakke@cisco.com>]

Paul Koning wrote:
> 
> >>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:
> 
>  Julian> Michael, The integer representation was discussed a long time
>  Julian> ago on the list and it was decided that decimal should be
>  Julian> allowed as it might be copied from some human readable
>  Julian> tables. I would hate to make this type of changes this late.
> 
> Was it ever the intent that things like Diffie-Hellman parameters
> could be expressed in decimal?  That seems like a VERY VERY bad idea;
> where is someone going to find a function that converts a decimal
> string to a bignum?
> 
> Decimal is fine for any parameter that's a "normal size" integer,
> i.e., a 32 bit or even -- probably -- a 64 bit integer.  But bignums
> should only ever be expressed in hex or base64.

I agree.

We tried to bring this up last summer.  Each key should specify
one and only one format, whether that's hex, base64, decimal,
whatever, that it MUST use, and leave it at that.  There is absolutely
no reason why an implementation should be able to choose to send
decimal for a key today, and hex tomorrow.  That way, there would
have been no need to parse "0x" in front of hex strings, etc.
It would have kept this a lot simpler, and I don't see a good reason
why anyone would want more flexibility than this.  Also, the
ability to use either upper or lower case for hex is a bit
unnecessary, but at least this shouldn't cause too much trouble.

Anyway, we already have a little section for each key specifying
what it does, and who can sent it.  It would be little trouble,
and probably greatly benefit interoperability, to just specify
for each text key which format its value uses, and stick with
it.  Why make life any harder for the receiver than it has to
be?

> 
>        paul

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054