> On Mar 18, 2019, at 8:22 PM, Graham Leggett <minfrin@xxxxxxxx> wrote:
>
> How would I decode the X509_REQ_INFO structure on the other side, turning it back into X509_REQ?
The function returns the DER form of the CRI, which can then be signed.
You can use d2i_X509_REQ_INFO() to get an X509_REQ_INFO, but indeed there's
not much you can do with that, other than DER-encode it again and sign.
Why do you need to do the encode and decode? What's wrong with the original
request object?
> While I can see a d2i_X509_REQ_INFO() function, I can’t find a corresponding function in openssl 1.1.0+ that assigns this to a X509_REQ, unless I am missing it?
It should not be needed.
> By way of concrete example, having crossed the module boundary we need to pull out details from the X509_REQ_INFO, which can only be done if this structure has been assigned to a X509_REQ first:
Can you be more specific about these "module boundaries"?
In any case, given the DER form of the CRI, it is easy to construct
the DER form of an enclosing CSR with a dummy signature:
0:d=0 hl=4 l= 360 cons: SEQUENCE -- Outer sequence and length: 30 82 01 68
4:d=1 hl=3 l= 210 cons: SEQUENCE -- DER encoding of CRI
7:d=2 hl=2 l= 1 prim: INTEGER :00
10:d=2 hl=2 l= 0 cons: SEQUENCE
12:d=2 hl=3 l= 159 cons: SEQUENCE
15:d=3 hl=2 l= 13 cons: SEQUENCE
17:d=4 hl=2 l= 9 prim: OBJECT :rsaEncryption
28:d=4 hl=2 l= 0 prim: NULL
30:d=3 hl=3 l= 141 prim: BIT STRING
174:d=2 hl=2 l= 41 cons: cont [ 0 ]
176:d=3 hl=2 l= 39 cons: SEQUENCE
178:d=4 hl=2 l= 9 prim: OBJECT :Extension Request
189:d=4 hl=2 l= 26 cons: SET
191:d=5 hl=2 l= 24 cons: SEQUENCE
193:d=6 hl=2 l= 22 cons: SEQUENCE
195:d=7 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternative Name
200:d=7 hl=2 l= 15 prim: OCTET STRING [HEX DUMP]:300D820B6578616D706C652E636F6D
217:d=1 hl=2 l= 13 cons: SEQUENCE -- Signature algorithm OID and parameters
219:d=2 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption
230:d=2 hl=2 l= 0 prim: NULL
232:d=1 hl=3 l= 129 prim: BIT STRING -- Signature data
In the above we see that the CRI, needs (typically) an ~4-byte prefix
of (0x30 + DER encoded length) and a suffix of the form:
30 0d -- 13 byte sequence
06 09 2a 86 48 86 f7 0d 01 01 0b -- 9 byte OID (sha256WithRSAEncryption)
05 00 -- NULL parameters
03 81 81 00 -- 128 byte bit string with 0 unused bits
xx xx xx xx ... xx -- 128 bytes of random data.
your random data could be all zeros. The trailer length is then a
fixed 147 bytes. Add that to the length of CRI and prepend the
outer sequence (0x30 + DER encoded (length CRI + 147)), then the
CRI and then the trailer, and presto-magic you have a CSR with
a bogus signature, but one that will encode and decode, just not
pass "req -verify".
This isn't pretty, and perhaps we need some new functions to explicitly
embed a CRI in a CSR, but it is certainly something you can do in the
short term.
--
Viktor.
