使用Rust CMS crate解码SCEP PKIOperation的PKCS7数据时解析SignedData失败
2026-4-7
Rust CMS crate解码SCEP PKIOperation的PKCS7数据时解析SignedData失败
我最近在处理SCEP协议中PKIOperation POST请求的PKCS7二进制数据解码，用的是Rust的CMS crate。一开始解析顶层的ContentInfo结构特别顺利：
let ci = ContentInfo::from_der(&body).unwrap();
但当我尝试解码内部的SignedData时，直接panic了：
let sd: SignedData = ci.content.decode_as().unwrap();
错误信息如下：
thread 'tokio-runtime-worker' panicked at src/web.rs:218:51: called `Result::unwrap()` on an `Err` value: Error { kind: Value { tag: Tag(0x02: INTEGER) }, position: Some(Length(129)) } note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
奇怪的是，用OpenSSL命令却能正常解析这个数据：
openssl cms -inform DER -in ci.der -cmsout -print
输出的结构如下：
CMS_ContentInfo: contentType: pkcs7-signedData (1.2.840.113549.1.7.2) d.signedData: version: 1 digestAlgorithms: algorithm: sha256 (2.16.840.1.101.3.4.2.1) parameter: NULL encapContentInfo: eContentType: pkcs7-data (1.2.840.113549.1.7.1) eContent: 0000 - 30 82 04 72 06 09 2a 86-48 86 f7 0d 01 07 03 0..r..*.H...... 000f - a0 82 04 63 30 82 04 5f-02 01 00 31 82 01 b6 ...c0.._...1... 001e - 30 82 01 b2 02 01 00 30-81 99 30 81 80 31 42 0......0..0..1B 002d - 30 40 06 03 55 04 03 0c-39 42 75 72 6e 74 20 0@..U...9Burnt 003c - 48 69 6c 6c 73 2d 42 61-6c 6c 73 74 6f 6e 20 Hills-Ballston 004b - 4c 61 6b 65 20 43 65 6e-74 72 61 6c 20 53 63 Lake Central Sc 005a - 68 6f 6f 6c 20 44 69 73-74 72 69 63 74 20 52 hool District R 0069 - 6f 6f 74 20 43 41 31 3a-30 38 06 03 55 04 0a oot CA1:08..U.. 0078 - 0c 31 42 75 72 6e 74 20-48 69 6c 6c 73 2d 42 .1Burnt Hills-B 0087 - 61 6c 6c 73 74 6f 6e 20-4c 61 6b 65 20 43 65 allston Lake Ce 0096 - 6e 74 72 61 6c 20 53 63-68 6f 6f 6c 20 44 69 ntral School Di 00a5 - 73 74 72 69 63 74 02 14-01 bf 08 ae 51 3f f8 strict......Q?. 00b4 - 82 1d 90 1f f4 7a 0f 25-32 00 35 5d f2 30 0d .....z.%2.5].0. 00c3 - 06 09 2a 86 48 86 f7 0d-01 01 01 05 00 04 82 ..*.H.......... 00d2 - 01 00 25 71 f4 7f 82 7a-30 98 8b 80 8d a4 79 ..%q...z0.....y 00e1 - ad 2e 00 28 a9 f8 7d 7c-3b 24 b9 86 43 64 3c ...(..}|;$..Cd< 00f0 - 5b d7 00 ba a2 1d 11 29-e7 8e dc c0 e1 ff 1f [......)....... 00ff - 83 77 eb 12 dd be 8f 41-8f d4 0e f2 57 4d c9 .w.....A....WM. 010e - bb 55 82 b1 d1 f6 39 06-87 27 10 72 f3 f4 fb .U....9..'.r... 011d - a0 45 ab 05 91 6a 82 67-ba 70 61 be d4 5e ec .E...j.g.pa..^. 012c - a1 b2 b1 25 1d bc 4c 16-f4 16 ae 11 c9 9f c4 ...%..L........ 013b - 74 15 65 17 d3 60 7d 6b-41 31 d2 83 bd 55 29 t.e..`}kA1...U) 014a - c5 bd 19 0b 37 a3 e6 5e-06 00 2a 28 91 79 58 ....7..^..*(.yX 0159 - 10 be 44 c6 61 75 e1 eb-43 5c 3d cb 6d 63 3d ..D.au..C\=.mc= 0168 - bb 60 f8 38 1c a9 b3 e1-6e ed 0e 1c 8f 46 29 .`.8....n....F) 0177 - b4 5f 38 d1 d6 03 1f ec-ad d6 64 71 cf b1 fb ._8.......dq... 0186 - d0 ed 8f 9e b9 a0 d2 52-a5 45 77 82 5f b2 69 .......R.Ew._.i 0195 - 37 af fa 1a 77 4f 60 99-7d ff 2c c5 ce 4d ee 7...wO`.}.,..M. 01a4 - 3e da 7d fc 6d 70 70 7d-03 e3 15 8a e8 89 04 >.}.mpp}....... 01b3 - 80 05 2a ad c7 7e c2 2d-ee fc 31 ac a3 ad ca ..*..~.-..1.... 01c2 - 57 a6 0e 02 d9 6a 01 86-d4 cb 21 d3 51 3a 0e W....j....!.Q:. 01d1 - a1 4d c2 30 82 02 9e 06-09 2a 86 48 86 f7 0d .M.0.....*.H... 01e0 - 01 07 01 30 1d 06 09 60-86 48 01 65 03 04 01 ...0...`.H.e... 01ef - 02 04 10 e5 a6 1c 9b bf-cb 28 04 2c 5d 1b 3a .........(.,].: 01fe - a6 86 15 57 80 82 02 70-87 75 2a 63 53 4f 32 ...W...p.u*cSO2 020d - fe ea 34 4b 99 e3 67 73-38 8b da 59 32 1a 16 ..4K..gs8..Y2.. 021c - 48 be 11 03 72 b3 bf 21-22 c7 c8 a3 89 e1 72 H...r..!".....r 022b - 3b cf 82 7d fd 60 3b 42-1a ce 4c 4d b2 27 ab ;..}.`;B..LM.'. 023a - 9d aa 09 5f 2d e8 1a bc-cb 2f da 41 47 7b 9c ..._-..../.AG{. 0249 - 97 c2 6c 12 a1 3f 4d 6c-95 39 49 fa 89 c7 da ..l..?Ml.9I.... 0258 - 63 46 91 76 ce 79 26 ef-2c 82 5f 82 59 80 3d cF.v.y&.,._.Y.= 0267 - b6 53 00 f3 d7 7c 63 0f-c9 66 20 bf 4d 7f 36 .S...|c..f .M.6 0276 - 5a 5a f4 d9 3a 49 3d df-2f 20 39 e1 bc d7 59 ZZ..:I=./ 9...Y 0285 - 9f ae 5c c4 a9 1b fb e3-c4 6a cc 03 bc ee 4f ..\......j....O 0294 - 9f e6 5f c6 56 dd 57 46-51 29 76 cc e7 9b b9 .._.V.WFQ)v.... 02a3 - da c4 96 fd 69 83 47 36-5e ad b8 f7 3f fc a4 ....i.G6^...?.. 02b2 - 41 56 67 90 85 35 3b 94-06 de 1d 43 de 69 32 AVg..5;....C.i2 02c1 - b3 12 a6 38 ae 39 6d b9-a3 65 51 2d a3 30 b5 ...8.9m..eQ-.0. 02d0 - a3 52 02 0d 39 d5 97 c6-30 8b f9 2e 1f 83 d3 .R..9...0...... 02df - 69 ba 5b cc ae ea 86 8e-9c 53 8a ae 20 d3 ab i.[......S.. .. 02ee - 92 d8 de 23 8c e0 86 b7-e6 06 01 7f 1d 7d a6 ...#.........}. 02fd - 8c 08 2c ad ca 4d 7d 41-7d 5d 83 68 43 57 9e ..,..M}A}].hCW. 030c - 4c c3 4a fa f3 73 05 21-df ff 7d ae 5c f7 78 L.J..s.!..}.\.x 031b - 45 f0 49 c6 d7 d4 78 94-64 ba 64 ee 45 cf d8 E.I...x.d.d.E.. 032a - d4 ba e3 5c 11 29 0c 85-97 25 8e 92 03 20 8f ...\.)...%... . 0339 - 12 3e 1f 9a 5b 2c 2b fd-1e 98 c5 5a eb 8e 39 .>..[,+....Z..9 0348 - a9 51 7b f7 3d 06 b7 24-78 00 56 2e 9e 5c 0b .Q{.=..$x.V..\. 0357 - e8 04 c8 fa 63 88 5e a1-7c 37 65 fa 8b 34 7d ....c.^.|7e..4} 0366 - 05 49 0e fd db 94 b9 1b-48 e4 88 c1 7c b4 73 .I......H...
问题分析
从错误信息来看，CMS crate在解析到位置129处的INTEGER类型字段时失败了。对比OpenSSL的输出，这个位置大概率对应SignedData里的某个字段——比如version字段（OpenSSL显示是1），或者digestAlgorithms里的参数？不过OpenSSL里参数是NULL，应该没问题。
我怀疑可能是CMS crate对SignedData的ASN.1解析逻辑和OpenSSL存在兼容差异：
- 可能是版本字段的编码问题：虽然ASN.1里version是INTEGER，但CMS crate可能期望的是更小的类型（比如u8），而数据里的INTEGER编码不符合它的预期
- 也可能是encapContentInfo里的eContent结构问题：OpenSSL显示eContent是pkcs7-data，里面嵌套了一个完整的DER结构，CMS crate可能对这种嵌套的解析处理得不够完善
尝试解决的方向
- 升级CMS crate版本：先确认你用的是不是最新版的CMS crate，旧版本可能存在解析兼容的bug，升级后说不定能解决
- 手动解析DER数据：不要直接用
decode_as()，先把ContentInfo的content转成原始DER：
然后用低级别ASN.1解析库（比如let content_der = ci.content.to_der().unwrap();asn1rs或者dercrate）手动解析SignedData的结构，定位到具体哪个字段出问题 - 对比ASN.1定义：查看CMS crate中SignedData的ASN.1定义，和RFC 2315（PKCS7）以及SCEP协议的要求对比，看看有没有字段定义不一致的地方
- 跳过错误字段：如果是某个非关键字段解析失败，可以尝试修改CMS crate的解析逻辑（或者自己封装一层），跳过该字段或者做兼容处理
内容来源于stack exchange
