On Tue, Feb 23, 2016, Dr. Stephen Henson wrote:
> On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:
>
> > I tried again to map the structure of the CMS object to the
> > definitions in RFC 5652 (comments added with a '%'):
> >
> > 1: SEQUENCE {
> > 2: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
> > % ContentType
> > 3: [0] { % eContent
> > 4: SEQUENCE {
> > 5: INTEGER 0 % CMSVersion
> > % no OriginatorInfo
> > 6: SET { % RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
> > 7: SEQUENCE {
> > % SEQUENCE tag should not be present because of implicit tagging?
>
> Yes, because it is using the key agreement choice type it should be
> tagged [1] IMPLICIT but it is not which is why OpenSSL thinks it is key
> transport.
>
> > 8: INTEGER 3
> > % version 3 only applicable to KeyAgreeRecipientInfo
> > 9: [0] {
>
> Assume this is KeyAgreeRecipientInfo.. the above tag would indicate the
> "originator" field.
>
> > 10: SEQUENCE {
>
> Here it is wrong again. The untagged form is "IssuerAndSerialNumber" which
> the fields below certainly aren't. It looks like originatorKey which should be
> tagged [1] IMPLICIT.
>
> > 11: SEQUENCE {
> > 12: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
> > 13: OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
> > 14: }
> >
>
> So yes it's pretty broken.
>
Just as a quick followup. If you change the two tags I mentioned above the
result does then parse. However I've no idea if it will actually decrypt: the
key derivation might be broken too.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
