Hi, [ I ran into this problem as a follow-up of the previous ECDSA question I asked earlier, but I assume this problem is independent. ]
I'm trying to use CERT_AsciiToName() to get the DER-encoded equivalent of a string from an XML signature. The original string from my XML signature was: "C=HU,L=Budapest,O=NISZ Nemzeti Infokommunikációs Szolgáltató Zrt.,CN=Állampolgári Tanúsítványkiadó - Qualified Citizen CA,UNDEF=VATHU-10585560" CERT_AsciiToName() fails for this, as nss/lib/certdb/alg1485.c's name2kinds table has no idea about "UNDEF", and researching a bit it seems to be indeed a custom construct, so I complained to the creator of the signature about this. As a reply they now improved, their replacement is: "C=HU,L=Budapest,O=NISZ Nemzeti Infokommunikációs Szolgáltató Zrt.,CN=Állampolgári Tanúsítványkiadó - Qualified Citizen CA,2.5.4.97=VATHU-10585560" This fails the same way, for the same reason. I guess what their intention was to encode the OID into the part before the "=" character, for an OID that is indeed advertised by ETSI, but has no IANA registered type name. Reading ParseRFC1485AVA() in same file my guess was the correct syntax would be: "C=HU,L=Budapest,O=NISZ Nemzeti Infokommunikációs Szolgáltató Zrt.,CN=Állampolgári Tanúsítványkiadó - Qualified Citizen CA,OID.2.5.4.97=VATHU-10585560" but before suggesting this to the creator of the signature (author of the software that generates this XML signature), I wanted to check if NSS is happy with it, and it's not. Here is how it fails exactly: In case of using the proper "OID." prefix, ParseRFC1485AVA() calls SEC_StringToOID() and that returns SECSuccess, but later the if (kind == SEC_OID_UNKNOWN) condition still leads to PORT_SetError(SEC_ERROR_INVALID_AVA) and thus CERT_AsciiToName() fails. So my question: am I right this is a bug in NSS? If absolutely needed, I could work around the problem in my client code, but it would be nice if NSS could handle the situation. I guess there are several options, like 1) teching NSS about this OID 2) ignoring unknown OIDs 3) allowing unknown OIDs and encoding them into the DER blob. At least it looks a bit confusing that the OID.x.y... syntax is supported, but unknown OIDs are not allowed. If the conclusion is that this new OID just has to be added to the list of OIDs NSS recognizes, I can try to craft a patch that does so. (Though so far I did not try to build NSS myself, I'm just using the distro debug packages.) Trivial reproducer: https://github.com/vmiklos/vmexam/blob/master/nss/test.cpp Thanks, Miklos -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
