On 19 Mar 2019, at 03:22, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote: >> 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? The code is a modular ca, and different modules communicate with each other generically using the standard DER encoded structures. Openssl isn’t visible through the API, it is an implementation detail. >> 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. I don’t follow - in order to get access to the data inside the X509_REQ_INFO structure, I need to first wrap it in a X509_REQ, otherwise I have no API calls to get access to the data inside it. >> 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”? The modules are Apache httpd modules, and the boundaries between the modules are hooks that pass DER encoded structures between each module. > 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. Can we not rather fix the initialisation of the X509_REQ in X509_REQ_new() so that it works like it used to? It seems like a massive headache to do something that used to be trivial. I see there have been changes to openssl code relating to how structures are initialised, I suspect an error has crept in where an ASN.1 object is missing instead of empty, thus the malformed CSR. Regards, Graham —
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
