Re: Experimental RFC to be: draft-khan-gaur-secure-mpeg-syntax-00.txt

[Steve Coya <scoya@ietf.org>]

The IESG, after review by some members of the S/MIME working group
(excluding the chair, who had a conflict of interest), has requested that
Cryptographic Message Syntax for MP3/MPEG I, II, and III Secure MPEG
(SMPEG) < draft-khan-gaur-secure-mpeg-syntax-00.txt> not be published in
its current form. Apart from anything else, the authors should re-evaluate
their approach, and think strongly about how it could be done using CMS.
This would allow for a faster spread of the standard they want. 

The document contains a number of issues that are not adequatly
addressed. These issues include security problems, underspecification
of some items and a lack of information needed to succesfully
implement the structures.

1. Certificates are identified by just a serial number
(recipientCertSerialNumber or venderCertSerialNumber). This is
insufficent information to actually find the certificate involved
in the transaction unless it is resticted to a single certificate
authority. A minimum of a serial number and issuer name or subject
key identifier is needed to identify a certificate used.

2. The IV used in the bulk encryption process is fixed to a single
value. While I don't know that the beginning of an MPEG stream is
not constant, this allows for a strong potential of doing a dictionary
attack to find the key which was used for the encryption process.

3. The signature processing includes the ASN.1 encoding (type and
length). This means that doing a re-encoding of the ASN.1 structure
(i.e. from indefinite to definite length encoding) will cause the
signature validation failure.

4. The method proposed for the encryption of the symmetric key is
flawed. It signs the symmetric key and then encrypts the signed
value using RSA PKCS#1 v1.5 for the recipients encryption key. This
may not work depending on the lengths of the encryption and signing
keys. (Consider a 2048-bit signing key and a 1024-bit encryption
key.) In reading section 5.2 step (d) it is not clear that this
is supposed to be done.

5. The signature includes the ASN.1 encoding of the encrypted
value. This means that if the structure is re-encoded during
transport (i.e. from indefinite to definite length encoding) the
signature will be invalidated.

6. Text strings are being encoded as OCTET STRING rather than
UTF8STRING.

Some other issues that are not fatal flaws but should be addressed

1. Playtime is represented as an OCTET STRING rather than an
integer.

2. symmetricAlg is defaulted to an algorithm that is being slowly
obsoleted. There is no benefit to setting a default here.

3. miscInfo is poorly though out. The structure of the value
should be explicit rather than implicit. As specified it corresponds
to pairs of strings (presummably zero terminated) that are concatenated
and encoded as an OCTET STRING.

4. The signature only includes the content and does not include
any of the associated data (such as the title).

5. No ability is included in the structure for either carrying
the vendor certificate used for the signature operation (along with
CRLs) or a pointer to the certificate used.