Definitions problem with PKCS#7 encrypted messages

[JamesTheAwesomeDude]

Taking this relatively straightforward password-protected message from openssl cms:

MIHYBgkqhkiG9w0BBwOggcowgccCAQMxgYOjgYACAQCgGwYJKoZIhvcNAQUMMA4E
CGG3gz/siGhzAgIIADAsBgsqhkiG9w0BCRADCTAdBglghkgBZQMEASoEEDbLqeP8
73zphgHJgA6f3ZUEMPp59XJmIxS+/q8gDtWlN4O6fau6KzHfzytpw31/mSErsnEl
6OySZvERFzJhRIbmFzA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCqMLOussRf
WJ4gE7JLtyI3gBDT03wv8+XfRnIPR5Cqelui

The site totally misinterprets it, trying to parse each element of the PasswordRecipientInfo (which is mis-identified as a generic RecipientInfo) as its own recipient:

[JamesTheAwesomeDude]

The key is that this is a CHOICE, not a SEQUENCE; the type of (each) recipient should be identified by the implicit tag on it:

https://datatracker.ietf.org/doc/html/rfc5652#section-6.2

DEFINITIONS IMPLICIT TAGS ::=
BEGIN
…
RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [1] KeyAgreeRecipientInfo,
  kekri [2] KEKRecipientInfo,
  pwri [3] PasswordRecipientinfo,
  ori [4] OtherRecipientInfo }

so each element of RecipientInfos may either have the universal sequence tag (which would make it a KeyTransRecipientInfo, which used to be the only type), an implicit 3 tag (which would make it a PasswordRecipientInfo), etc.

[lapo-luchini]

Sorry about being late.
Recent refactoring in 6f4b911 should make this a bit easier.
Type matching is still an early release.

[lapo-luchini]

Oh, I see: the tag is used as if it was EXPLICIT, so being IMPLICIT all the parsing out of sync and the first child is seen as the value.

[JamesTheAwesomeDude]

Hmm, after the update the behavior is different — and better — but still wrong.

Using the example from the OP, it's identifying the version field = 0 as the PasswordRecipientInfo itself, when its type should only be CMSVersion.