Closed OTP-Maintainer closed 4 months ago
ingela
said:
As we already have a workaround ASN-1 read spec it could be possible to make the workaround a little more forgiving.
I am not sure how big we should allow though in that case. 10 letters 20 letters? In that case, there would be no error generated to the verify fun.
It would be fairly easy to make a
{code:java}
{bad_cert, cert_decode_error}
{code}
but being specific about what part of the ASN-1 spec would proabably not be as trivial.
jwheare
said:
I would favour not adding any limit in the asn-1 spec that would cause a hard failure. Perhaps it could accept any value but add a new validation check called from `public_key:validate`, something like `pubkey_cert:validate_country` that checks the length and produces `bad_cert`. Looking at the existing `bad_cert` failures, none of them are particularly appropriate. Perhaps a new `invalid_country` error would work.
ingela
said:
The existing public_key:validate functions validate properties of certificates on a higher abstraction level. These are the properties of the X509 cert RFC, so it is not surprising that the failures does not match. It is sort of expected that the certificates shall follow the spec. The idea is however interesting. validate_country name would be very specific and I think it would be nice to have a more general validate_decode. {bad_cert, {cert_decode_error, Error}} where Error might be something like {countryname, invalid_length}.
ingela
said:
This would probably need new error handling in asn1 application and is not prioritized.
We think there is no reasonable way to work around this particular breakage of the specification in comparison to what we gain. We are considering some flexibility to public_key:path_validation function that might provide a way to handle decoding errors in general, but it would require the user to have its own ASN1 decoding function.
Original reporter:
jwheare
Affected version:OTP-19.3.1
Component:public_key
Migrated from: https://bugs.erlang.org/browse/ERL-423