2
$\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$
  • 2
    $\begingroup$ OIDs don't have a maximal length / depth (in theory, in praxis it is limited by RAM I guess). $\endgroup$ – SEJPM Mar 18 '17 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$ – Ian Spence Mar 18 '17 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 Mar 18 '17 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$ – Ian Spence Mar 19 '17 at 16:33
  • $\begingroup$ Okidoki, did just that. $\endgroup$ – Maarten Bodewes Mar 21 '17 at 0:19
3
$\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$
  • 1
    $\begingroup$ FWIW, a cert chain used in SSL/TLS is limited to $2^{24}-1$ bytes. $\endgroup$ – dave_thompson_085 Mar 21 '17 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 Mar 21 '17 at 8:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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