What threats and mitigations are there for a CA when processing a CSR?

Question

Question

What kinds of technical nastiness/attacks should I look for in a Certificate Request (CSR) ?

Assume the ASN1 parser is secure on the CA. I'm strictly concerned with the process of validating the data of the CSR.

More information

Suppose the CA recieves the following CSR

The CA will strip out the "begin/end" headers and footers and parse the data. Humans can achieve a similar effect here.

As you can see there are a set of OIDs that have corresponding printable string values.

My goal is to prevent privilege escalation, or impersonation attacks that could arise with a malformed CSR.

I assume you are asking as a CA who wants to validate CSRs? I mean, as a CA, you are responsible for validating all of the information before issuing the certificate; that's the primary function of the CA. Are asking "what kinds of technical nastiness/attacks should I look for?" — John Deters, Feb 09 '17 at 15:52
@JohnDeters - yes, just rephrased. One example could be duplicated OIDs, missing OIDs, wrong datatype, XSS in certain fields, XSS reflection, bad punycode, bad UTF8/32 if supported, any attempt to include an EKU reserved for the server to apply... — makerofthings7, Feb 09 '17 at 15:59
I also assume you're validating it fully conforms to RFC5280. Check the Security section of the document, it addresses some of the character encoding concerns you raised. https://tools.ietf.org/html/rfc5280#page-100 Also consider looking at the referenced RFCs; many of them go into specific details (their relevant text seems to have been carried into 5280, but some have additional sections like Security.) — John Deters, Feb 09 '17 at 16:26

score 0 · Accepted Answer · answered Feb 09 '17 at 16:54

CA's usually don't use the originally provided CSR and just sign it. Instead they extract and verify only the information they want to include in the certificate from the CSR (i.e. public key, subject..), add some additional information like expiration, CRL distribution point, OCSP URL etc and then they sign this newly created CSR. This way the CA does not need to deal with OID or similar it does not understand since these information are not included in the generated certificate anyway. It only needs to understand and verify the parts it will include from the original CSR, i.e. only few parts. And these parts usually have a well known syntax which can be enforced, for example a domain name.

What threats and mitigations are there for a CA when processing a CSR?

1 Answers1