[openssl-users] Is the structure of this CMS object correct?

Dr. Stephen Henson steve at openssl.org
Thu Feb 25 12:16:40 UTC 2016


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


More information about the openssl-users mailing list