Re: CERT_AsciiToName() and unknown OIDs

On 02/23/2017 09:00 AM, Miklos Vajna wrote:
> 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.)

You should follow the RFC specifications, in this case RFC-4514 and 
RFC-4512.

The second example with the RDN 2.5.4.97=VATHU-10585560 is correct.

It does appear that ParseRFC1485AVA has a bug

     if (!PL_strncasecmp("oid.", tagBuf, 4)) {
         rv = SEC_StringToOID(arena, &derOid, tagBuf, strlen(tagBuf));

SEC_StringToOID() can handle a numericoid (e.g. dotted decimal) with or 
without a "OID." prefix. The test should include a test for a numericoid.

FWIW the code is implementing a very old obsoleted RFC the "oid." prefix 
comes from RFC-1485 published in 1995, the current RFC 4514 is from 2006.

RFC 4514 obsoletes 2253 which obsoletes 1779 which obsoletes 1485.


-- 
John
-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto