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
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
