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
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime