Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definitions problem with PKCS#7 encrypted messages #67

Open
James-E-A opened this issue May 17, 2023 · 4 comments
Open

Definitions problem with PKCS#7 encrypted messages #67

James-E-A opened this issue May 17, 2023 · 4 comments

Comments

@James-E-A
Copy link

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:

image

@James-E-A James-E-A changed the title Definitons problem with PKCS#7 encrypted messages Definitions problem with PKCS#7 encrypted messages May 17, 2023
@James-E-A
Copy link
Author

James-E-A commented May 17, 2023

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
Copy link
Owner

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

@lapo-luchini
Copy link
Owner

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.

@James-E-A
Copy link
Author

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.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@lapo-luchini @James-E-A and others