Re: SSH in ECC Internet Draft

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

Jon Green wrote:
> On Tue, 2006-10-10 at 11:17 -0500, Nicolas Williams wrote:
>> On Wed, Oct 11, 2006 at 01:52:24AM +1000, Damien Miller wrote:
>>> IMO that (some) ECC libraries happen to use ASN.1 is not a good reason
>>> to use it as protocol element.
>> The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where
>> existing SSHv2 constructs could be used instead.  The draft's other uses
>> of ASN.1/DER do not require an implementation of SSHv2 to implement
>> ASN.1/DER outside ECC libraries, but this one type does.
> 
> I don't think that we can just remove curves and send a name-list of
> OIDs. Encoding and parsing a ASN.1 sequence is easier then encoding and
> parsing a ssh namelist full of octet strings. 
> 
> So everyone is familiar with what an asn.1 sequence looks like:
> [ identifier | length | oid | oid | oid | oid | ...
> where each oid contains
> [ identifier | length | oid data ]
> 
> The first problem with putting OIDs in name-lists is that the one of the
> octets in the OID octet string may be 0x2C (ascii comma) which delimits
> the list, so the OIDs will have to be encoded somehow before being put
> into a standard namelist, or there has to be a new type of list
> defined. 

If, as it appears, we only need a list of oids, I can think of
two ways to do this 'the ssh way.'

1. Encode each oid in the numeric dotted ascii format,
   i.e., "1.2.840.113554.1.2.2"; comma seperate them,
   and send as a single string.

2. Encode as
   uint32 uCount
   string oid-octet-strings[uCount]

   or

   string curves
       string oid
       string oid
       string oid
       ...

> Any list constructs I came up with seemed to be very similar to the
> ASN.1 sequence of construct, so i decided to use it. Would including
> some psudocode in the draft to encode and parse 'curves' maybe be a good
> idea?
> 
> I like using the OIDs to identify curves since there is an already
> existing IANA registry and we don't have to reinvent the wheel this
> way. 

Oh... definitely keep the oids... I don't think anyone is arguing
against using oids.

Thanks,

Joseph