You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The certificate "accessLocation" field is (at heart) an Internationalized Resource Identifier (IRI).
However, the RFC wants it "mapped" (whatever that means) into an Uniform Resource Identifier (URI) when stored in the certificate.
URIs are "sequences of characters from the ASCII character set." (It's not clear whether it equals ASCII or is a subset of ASCII, needs research.)
The field type of the URI is "IA5String". IA5String allows a subset of ASCII. (So it's not clear whether it's entirely compatible with the URI charset, needs research.)
Fort converts those IA5Strings to file paths in the local filesystem.
I think the gist of it is that the RFC's mention of IRIs made me afraid of characters that could translate incorrectly at some point on their way to become file names. Since the certificate field is supposed to be in URI form, it "should" (in theory) convert bureaucracylessly into a IA5String, and the IA5String "should" convert bureaucracylessly into a file name because it's a small subset of ASCII. So the question is whether URIs are fully compatible with IA5Strings.
But also, unless libcrypto does it somewhere, I don't think Fort is validating the IA5String contained in the certificate is, in fact, a valid IA5String.
So this might be a security vulnerability against malicious certificates.
The text was updated successfully, but these errors were encountered:
Old warning that popped up during a review. I believe this was the train of thought:
I think the gist of it is that the RFC's mention of IRIs made me afraid of characters that could translate incorrectly at some point on their way to become file names. Since the certificate field is supposed to be in URI form, it "should" (in theory) convert bureaucracylessly into a IA5String, and the IA5String "should" convert bureaucracylessly into a file name because it's a small subset of ASCII. So the question is whether URIs are fully compatible with IA5Strings.
But also, unless libcrypto does it somewhere, I don't think Fort is validating the IA5String contained in the certificate is, in fact, a valid IA5String.
So this might be a security vulnerability against malicious certificates.
The text was updated successfully, but these errors were encountered: