ECPoint and compression

Hello SMIME list.

Is there any interest in having a usable compression format that 
implementations would find appealing implement/enable?

SMIME stands out in my mind because of the storage benefit in case of a 
short message ECC-encrypted to a large number of recipients. In this 
common scenario the size of security-related overhead may be comparable 
or often exceeds the plaintext payload.

CMS ECC RFC (http://tools.ietf.org/html/rfc5753) refers to SPKI RFC 
(http://tools.ietf.org/html/rfc5480) with the following details about 
ECPoint:

>
>       2.2 <http://tools.ietf.org/html/rfc5480#section-2.2>. Subject
>       Public Key
>
>
>
>     The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key.
>     ECC public keys have the following syntax:
>
>       ECPoint ::= OCTET STRING
>
>     Implementations of Elliptic Curve Cryptography according to this
>     document MUST support the uncompressed form and MAY support the
>     compressed form of the ECC public key.  The hybrid form of the ECC
>     public key from [X9.62  <http://tools.ietf.org/html/rfc5480#ref-X9.62>] MUST NOT be used.  As specified in [SEC1  <http://tools.ietf.org/html/rfc5480#ref-SEC1>]:
>
>        o The elliptic curve public key (a value of type ECPoint that is
>          an OCTET STRING) is mapped to a subjectPublicKey (a value of
>          type BIT STRING) as follows: the most significant bit of the
>          OCTET STRING value becomes the most significant bit of the BIT
>          STRING value, and so on; the least significant bit of the OCTET
>          STRING becomes the least significant bit of the BIT STRING.
>          Conversion routines are found in Sections2.3.1  <http://tools.ietf.org/html/rfc5480#section-2.3.1>  and2.3.2  <http://tools.ietf.org/html/rfc5480#section-2.3.2>  of
>          [SEC1  <http://tools.ietf.org/html/rfc5480#ref-SEC1>].
>
>        o The first octet of the OCTET STRING indicates whether the key is
>          compressed or uncompressed.  The uncompressed form is indicated
>          by 0x04 and the compressed form is indicated by either 0x02 or
>          0x03 (see 2.3.3 in [SEC1  <http://tools.ietf.org/html/rfc5480#ref-SEC1>]).  The public key MUST be rejected if
>          any other value is included in the first octet.

I wrote a proposal for, I will argue, a better format here:

    http://tools.ietf.org/html/draft-jivsov-ecc-compact

IMO the business of 1 bit preservation is an unnecessary complexity, 
especially in ECDH scenarios.

One way to integrate the compact representation above is to say that 
OCTET STRING above is simply the "x" of the point. Given that this 
encoding is always 1 byte shorter than the SEC1, this overloading is 
unambiguous.

Is there interest in this proposal? Would it make a difference in the 
actual usage of the compact representation?

( My other immediate plan with this format is to use it as the format 
for OpenPGP analog of the ECPoint. )

Thank you.
_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime