On May 3, 2014, at 2:41 PM, Kevin Le Gouguec <kevin.le-goug...@insa-lyon.fr>
wrote:
> Using asn1parse, I got this:
>
> 0:d=0 hl=4 l=3980 cons: SEQUENCE
> 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-envelopedData
> 15:d=1 hl=4 l=3965 cons: cont [ 0 ]
> 19:d=2 hl=4 l=3961 cons: SEQUENCE
> 23:d=3 hl=2 l= 1 prim: INTEGER :00
> 26:d=3 hl=4 l= 304 cons: SET
> 30:d=4 hl=4 l= 300 cons: SEQUENCE
> 34:d=5 hl=2 l= 1 prim: INTEGER :02
> 37:d=5 hl=2 l= 20 prim: cont [ 0 ]
> 59:d=5 hl=2 l= 13 cons: SEQUENCE
> 61:d=6 hl=2 l= 9 prim: OBJECT :rsaEncryption
> 72:d=6 hl=2 l= 0 prim: NULL
> 74:d=5 hl=4 l= 256 prim: OCTET STRING [HEX DUMP]:<SNIP ENCRYPTED
> KEY>
> 334:d=3 hl=4 l=3646 cons: SEQUENCE
> 338:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
> 349:d=4 hl=2 l= 29 cons: SEQUENCE
> 351:d=5 hl=2 l= 9 prim: OBJECT :aes-256-cbc
> 362:d=5 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:<SNIP IV>
> 380:d=4 hl=4 l=3600 prim: cont [ 0 ]
>
> ator
> Info, SET of Recipient Info, ... }. So I guess here the version number is 0?
> This is weird, since I'm using a Subject Key Identifier: this condition "must"
> set the RecipientInfo's version field to 2 (which is happening), which in
> turn should
> make the EnvelopedData's version also 2 (which is not happening).
>
> ... Weird.
Yeah, that looks wrong to me, too. It should be 2. It probably doesn’t cause
any trouble most of the time, since the idea is that you won’t check the
version number unless you get a decode error. Perhaps someone can confirm
we’re not missing something? Here’s the bit of the RFC (from section 6.1) that
I believe indicates the version should be 2:
The fields of type EnvelopedData have the following meanings:
version is the syntax version number. The appropriate value
depends on originatorInfo, RecipientInfo, and unprotectedAttrs.
The version MUST be assigned as follows:
IF (originatorInfo is present) AND
((any certificates with a type of other are present) OR
(any crls with a type of other are present))
THEN version is 4
ELSE
IF ((originatorInfo is present) AND
(any version 2 attribute certificates are present)) OR
(any RecipientInfo structures include pwri) OR
(any RecipientInfo structures include ori)
THEN version is 3
ELSE
IF (originatorInfo is absent) AND
(unprotectedAttrs is absent) AND
(all RecipientInfo structures are version 0)
THEN version is 0
ELSE version is 2
>
>
>> (Parsing ASN.1 stuff)
>
> Yup, I think I got the idea of how ASN.1 works, and I'm starting to be pretty
> familiar with the CMS RFC (and its various updates). The thing is, I'm having
> trouble finding a decent parser ; I've tried compiling the CMS ASN.1 spec
> into C
> classes with e.g. asn1c, but all the ASN.1 compilers I've tried choke on the
> syntax as it is written in the RFC (I also tried the spec from RFC 6268 but
> the
> programs still can't compile it).
I thought asn1c (and most others) had been updated to use the latest syntax,
but I’m guessing that’s not the case. The older syntax is very similar, I
wouldn’t expect it to be very hard to update it, just be aware that the reason
for the newer syntax was to make some things more explicit, where different
ASN.1 compilers would handle the same syntax slightly differently.
> Should I bother using OpenSSL's ASN.1 API or should I continue trying to get
> an
> ASN.1 compiler to work with the CMS spec?
I typically just use OpenSSL, even if I’m not using anything else from OpenSSL.
According to the docs, there’s stuff it doesn’t handle, but the limitations
have never bothered me (not that my needs have been complex!). It also means I
need to set things up using OpenSSL’s macros rather than have it compile ASN.1
syntax like asn1c would do, but I generally dislike dealing with generated
source code, unless it’s Java. :)
TOM
<snip>______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
