>From: jefft(_at_)COM(_dot_)RSA (Jeff Thompson)
>Subject: SIGNED Macro and PEM Signatures
>Date: Mon, 8 Mar 93 09:32:09 PST
>
>certificate issuer's public key (Low Assurance PCA):
>
>30 7c 30 0d 06 09 2a 86 48 86 f7 0d
>01 01 01 05 00 03 6b 00 30 68 02 61
>00 b0 b4 0e 9a 3a 46 4e 87 03 ff b8
>db ca d8 af 41 f3 c3 f4 13 1c f6 57
>1e 39 a5 35 49 b4 20 94 dc 92 f8 ee
>1e a1 03 5f 94 21 2b 75 1a 3b 07 44
>5d bd d6 ef 4d 7e 23 00 f4 2c f5 73
>47 90 bc e8 ba 51 7f a8 19 ee f7 5f
>17 46 dc e5 ff d1 23 fe 64 2e 68 94
>b3 81 de 5a 40 28 8d d6 d7 14 af 84
>ef 02 03 01 00 01
I guess this is actually the X.509 subjectPublicKeyInfo of
the enclosing certificate, not X.509 C.3 subjectPublicKey...
Thanks for the example. I eventually pulled the subjectPublicKey
from the bitstring. This minor, but unnecessary, semantic problem confused
us, and our certificate checker, for a while.
I encourage *the* worked example to return to the design (section 2.2)
of "Some examples of the PKCS standards". It was clearer.
-------------------
( UNIV SEQ
( UNIV SEQ
( UNIV OID 0x9
0x2a864886
0xf70d0101
0x01
)
( UNIV NULL 0x0 )
)
( UNIV BITS 0x6b
0x00306802
0x6100b0b4
0x0e9a3a46
0x4e8703ff
0xb8dbcad8
0xaf41f3c3
0xf4131cf6
0x571e39a5
0x3549b420
0x94dc92f8
0xee1ea103
0x5f94212b
0x751a3b07
0x445dbdd6
0xef4d7e23
0x00f42cf5
0x734790bc
0xe8ba517f
0xa819eef7
0x5f1746dc
0xe5ffd123
0xfe642e68
0x94b381de
0x5a40288d
0xd6d714af
0x84ef0203
0x010001
)
)
subjectPublicKeyInfo {
algorithm {
algorithm 1.2.840.113549.1.1.1,
parameters NULL
},
subjectPublicKey
'003048024100c5596591f670ac387fbabff6c0d083e593220e0bc3a00f975b9eb7ad514c777bae14252df83058747f177eac9c1da5394d33ebd8de9216a41c69d2d4838fa4510203010001'H
}