Issues with draft-ietf-smime-examples-05

When working with IETF's draft-ietf-smime-examples-05 I discovered some
issues that I would like to present and probably needs to be fixed. If I am
wrong I would appreciate if someone could explain it to me.

- AliceRSASignByCarl.cer:
The asn1dump of the certificate in the draft-text is not a correct
representation of the binary certificate. The binary certificate has has a
different OID for the signature algorithm identifier (sha-1WithRSAEncryption
(1 3 14 3 2  29)) which also results in a different signature value.
Alice's RSA certificate conveyed within the example messages (for example
5.2) has the OID that the draft-text specifies. If using the stand-alone
binary certificate, this could lead to a conflict where you have two binary
different certificates with the same issuer and serial number.
I suppose that the stand-alone binary form ("AliceRSASignByCarl.cer") needs
to be updated to be the same as the one present in the binary examples and
the draft-text.

- CRL's and nextUpdate field:
None of the CRLs in the examples have the nextUpdate field present. I know
that the field is optional in the ASN1 spec, but it is required to be
present according to RFC 2459, sec 5.1.2.5.

- example 6.2:
The asn1dump of the example present in the draft-text is not a correct
representation of the binary form of the 6.2 example.
For example: before the asn1dump the draft-text declares that the example
does not have an OriginatorInfo field, which is correct in the binary
example but not according to the asn1dump that follows in the draft-text.
There are also a lot of other differences but I will leave out those
details. I suppose that the binary version of the example is the correct one
and the asn1dump in the draft-text needs to be updated.

If the binary version of the example is the correct one, there is an
incorrect version number of the KeyTransRecipientInfo field.
Since the RecipientIdentifier is of the IssuerAndSerialnumber choice the
version number should be 0 and not 2 (RFC 2630, sec 6.2.1).

Below is my asn1dump of the KeyTransRecipientInfo field of the binary
version of the 6.2 example:
  30 30  187:         SEQUENCE {
  33 02    1:           INTEGER 2
  36 30   38:           SEQUENCE {
  38 30   18:             SEQUENCE {
  40 31   16:               SET {
  42 30   14:                 SEQUENCE {
  44 06    3:                   OBJECT IDENTIFIER commonName (2 5 4 3)
  49 13    7:                   PrintableString 'CarlRSA'
            :                   }
            :                 }
            :               }
  58 02   16:             INTEGER
            :               46 34 6B C7 80 00 56 BC 11 D3 6E 2E CD 5D 71 D0
            :             }
  76 30   11:           SEQUENCE {
  78 06    9:             OBJECT IDENTIFIER
            :               rsaEncryption (1 2 840 113549 1 1 1)
            :             }
  89 04  128:           OCTET STRING
            :             45 1E C2 3C B5 4A DA DD CD F0 1F CF BE 2F 90 E4
            :             54 DB 57 DC 87 40 E9 99 35 51 64 50 1B D0 5E 1C
            :             94 DC E9 9B 9F F8 B1 40 E4 F8 91 09 9D F8 F7 E5
            :             19 DB 43 38 69 70 E7 67 36 E1 0E E6 4A 73 B0 DF
            :             19 AD 0E 47 4F 13 27 57 2C E9 81 F3 F1 A6 DF 1F
            :             B6 B2 1D 32 D0 50 BE 0D 73 E1 D0 E3 27 FC 70 F4
            :             05 8E DA D9 42 02 00 16 3F 64 26 45 9B F8 98 29
            :             0C 68 09 94 E8 61 F9 09 4B 73 35 82 9A CE D0 8B
            :           }


Regards,
Magnus Svensson