i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287

[Viktor Dukhovni]

> On Mar 18, 2019, at 8:22 PM, Graham Leggett <minfrin at sharp.fm> 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.