ietf-smime
[Top] [All Lists]

Re: Compressed data type for S/MIME

1999-08-04 09:27:52

What would it take to get SSL/TLS, IPSEC, and some of the other protocols
to adopt CMS, if that is the preferred solution?


Bob,

  That wouldn't work.  CMS is about Independent Data Unit Protection,
whereas both IPSEC and TLS are stream protection mechanisms.  (IPSEC
protects individual packets, but relies on a previously established
Security Association to provide the symmetric key for that protection).

Besides, both IPSEC and TLS have their own unique syntax representation
languages, and wouldn't want to use CMS's ASN.1 :-).

Dave



---------------- snip here to avoid rant ----------------------

I've often wondered whether ASN.1 could be used to express the bits on
the wire of an existing protocol such as IPSEC's AH.   To do so, one
would need to define "Fixed-field Encoding Rules" (FER) which would
place only data (not tag or length) octets in the datastream, and a set
of macros to conveniently represent the necessary fields.

For example:

   Int8  ::= INTEGER (0..255)
   Int16 ::= INTEGER (0..65535)
   Int32 ::= INTEGER (0..<4G>)
   
   AuthenticationHeader ::= SEQUENCE {
       nextHeader          Int8,
       payloadLen          Int8,
       reserved            Int16,
       spi                 Int32,
       sequenceNumber      Int32,
       authenticationData  OCTET STRING }


The bits-in-boxes notation used by IPSEC is easy for humans to read and
steeped in tradition, even if not easily machine readable.  But inventing a
unique language for the sole purpose of describing SSL 3.0 strikes me as,
well, goofy.  Wouldn't a protocol-independent description language be
easier on everyone?