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
This is probably not a bug of this library itself, but rather of everyone else :) Still, I think it's worth documenting.
I've ran several days ago in the wild into a couple of "valid" certificates[1] that had the serialNumber component of the subject field encoded as UTF8String . We're using sop/x509 to parse certificates (which in turn uses sop/x501) which failed to parse them (pretty justified, since both RFC3280 and X.520 define the X520serialNumber field as PrintableString). As far as I can tell these standards have at most been updated (by RFC4630 at least) to permit UTF8String values in fields defined as DirectoryString, and I have yet to find an updated standard that redefines serialNumber as such.
The sad part is that those certificates have been happily used so far with no issues and the holders are none the wiser (I ran into them as qualified signatures of a legal document). I've dug into how OpenSSL parses the certificate and it seems it happily accepts any string value when parsing RDNs. I presume lots of other libraries are doing the same.
Again, this is not a bug of sop/x501 in itself, more of a warning that enough parsers out there are operating in "quirks mode" that strictly enforcing the standard could cause several lost days chasing the issue. I'll personally try to weasel my way out of parsing the entire certificate or at worst consider a local and shameful fork that allows all components of a DN to be any kind of string :(
[1] I'm not including the certificates since I can't obtain permissions from their owners, but they have been issued by Eurocert, with issuer "organizationIdentifier = VATPL-9512352379, C = PL, O = EuroCert Sp. z o.o., CN = Centrum Kwalifikowane EuroCert", authority key identifier 74:62:70:99:FF:1B:60:3B:C4:64:B5:84:1F:A3:15:0C:5C:CB:5F:BD . It's a legit CA, added to the European Trusted List and everything . I will also try to contact them to consider being more strict in the future, but I don't expect much and it's possible that other CAs are doing the same thing.
The text was updated successfully, but these errors were encountered:
This is probably not a bug of this library itself, but rather of everyone else :) Still, I think it's worth documenting.
I've ran several days ago in the wild into a couple of "valid" certificates[1] that had the serialNumber component of the subject field encoded as UTF8String . We're using sop/x509 to parse certificates (which in turn uses sop/x501) which failed to parse them (pretty justified, since both RFC3280 and X.520 define the X520serialNumber field as PrintableString). As far as I can tell these standards have at most been updated (by RFC4630 at least) to permit UTF8String values in fields defined as DirectoryString, and I have yet to find an updated standard that redefines serialNumber as such.
The sad part is that those certificates have been happily used so far with no issues and the holders are none the wiser (I ran into them as qualified signatures of a legal document). I've dug into how OpenSSL parses the certificate and it seems it happily accepts any string value when parsing RDNs. I presume lots of other libraries are doing the same.
Again, this is not a bug of sop/x501 in itself, more of a warning that enough parsers out there are operating in "quirks mode" that strictly enforcing the standard could cause several lost days chasing the issue. I'll personally try to weasel my way out of parsing the entire certificate or at worst consider a local and shameful fork that allows all components of a DN to be any kind of string :(
[1] I'm not including the certificates since I can't obtain permissions from their owners, but they have been issued by Eurocert, with issuer "organizationIdentifier = VATPL-9512352379, C = PL, O = EuroCert Sp. z o.o., CN = Centrum Kwalifikowane EuroCert", authority key identifier 74:62:70:99:FF:1B:60:3B:C4:64:B5:84:1F:A3:15:0C:5C:CB:5F:BD . It's a legit CA, added to the European Trusted List and everything . I will also try to contact them to consider being more strict in the future, but I don't expect much and it's possible that other CAs are doing the same thing.
The text was updated successfully, but these errors were encountered: