4
$\begingroup$

I'm working on a feature for a project to determine if a given X.509 certificate is an EV Certificate, and if so, who is the authority behind that certificate.

To do this, I grabbed the list of EV OIDs from Wikipedia, and keep them in a hash of OID -> Authority Name. I get the certificate policy OID and convert it into a char array that I can use in my hash.

However I'm unsure about what the maximum length of a OID can be. I'm having trouble locating that information in the spec or anywhere else online.

$\endgroup$
5
  • 2
    $\begingroup$ OIDs don't have a maximal length / depth (in theory, in praxis it is limited by RAM I guess). $\endgroup$
    – SEJPM
    Commented Mar 18, 2017 at 19:26
  • $\begingroup$ Alright. Two follow up questions then: 1) what would be an appropriate limit at which to cut off at? I'm currently using 1K but that feels like too much. And 2) could you not DoS SSL clients by providing a OID more than the size of RAM? $\endgroup$
    – ecnepsnai
    Commented Mar 18, 2017 at 22:02
  • $\begingroup$ @IanSpence There is no real value you can put on that, but anything over 20 bytes seems ridiculous already. If I were somebody planning to protect against DoS attacks from certificates I'd limit the amount of bytes of the entire certificate rather than each and every component within the certificate. That said: why are you bothering about a measly 1 KB of RAM? Oh, and if programmed in C I'd rather be bothered about ASN.1 based buffer overruns, those are common enough and extremely dangerous. $\endgroup$
    – Maarten Bodewes
    Commented Mar 18, 2017 at 23:25
  • $\begingroup$ Alright, thanks! I'll do some research on ASN.1 overruns. Feel free to sum all this up in an answer and I'll mark it as correct. $\endgroup$
    – ecnepsnai
    Commented Mar 19, 2017 at 16:33
  • $\begingroup$ Okidoki, did just that. $\endgroup$
    – Maarten Bodewes
    Commented Mar 21, 2017 at 0:19

1 Answer 1

7
$\begingroup$

OIDs don't have a maximal length / depth specified. There is no real value where you can safely cut them off - or rather reject them (raise an exception or error). Anything over 20 bytes seems ridiculous, so that should be plenty. Limiting to a measly 1 KB of RAM should be fine on a non-embedded platform (desktop / server) as well, if you must set a limit.

When planning to protect against DoS attacks from certificates it is more useful to limit the amount of bytes of the entire certificate. It's not very efficient to limit each and every component within the certificate.


When programming in C/unmanaged C++ it is more reasonable to bother about ASN.1 based buffer overruns; those are common enough and extremely dangerous.

$\endgroup$
2
  • 1
    $\begingroup$ FWIW, a cert chain used in SSL/TLS is limited to $2^{24}-1$ bytes. $\endgroup$ Commented Mar 21, 2017 at 4:28
  • $\begingroup$ 16 MiB (17 MB) seems a bit excessive for a certificate though - or an OID for that matter :) $\endgroup$
    – Maarten Bodewes
    Commented Mar 21, 2017 at 8:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.