Open James-E-A opened 1 year ago
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.
Sorry about being late. Recent refactoring in 6f4b911c4f1477e8fd7d3625edd257cbceba0e97 should make this a bit easier. Type matching is still an early release.
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.
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
.
Taking this relatively straightforward password-protected message from
openssl cms
:The site totally misinterprets it, trying to parse each element of the
PasswordRecipientInfo
(which is mis-identified as a genericRecipientInfo
) as its own recipient: