Open BrainUser314 opened 10 months ago
Hi, thanks for this suggestion!
Could you give some more detail about what specifically you mean? Which attributes would you like to set in the CSR struct? We already have support for the PKCS9 extensionRequest
attribute, but currently no others.
Hi @davidhorstmann-arm,
I don't know about OP's use-case, but I would like to use something like the PKCS#9 randomNonce attribute type (see section 5.3.4 Random nonce in RFC2985, though I would like to use it for a PKCS#10 CSR, not for PKCS#7 signed data).
This is useful in automatic on-boarding of devices using Mbed TLS for client auth. I do something similar to what is described in CMP. Basically:
These steps occur over a secure medium, but may be unauthenticated for clients that do not yet have a certificate.
By including a random nonce in step 1, the client can include this in the CSR in step 2. In step 3, the RA can then assert the CSR is associated to a known certification process. Including the nonce in the (signed CSR) ensures for the RA that the client (or an attacker) did not e.g. re-use an old CSR.
Not using the random nonce makes the RA vulnerable to bad actors sending CSRs to the RA and getting back a client certificate. There are other mechanisms that prevent this, but they are not proven to be secure (and not easy to prove). A signature of a random nonce is. This could off-course be added outside of the CSR, but that means:
In general, I would like the Mbed TLS CSR generation API to support attributes. They are quite handy for a variety of use cases.
Suggested enhancement
the ability to add attributes and setting them to the csr struct
Justification
Mbed TLS needs this because it needs to implement full csr support