CERT_AsciiToName() and unknown OIDs

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

CERT_AsciiToName() and unknown OIDs

Miklos Vajna
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: CERT_AsciiToName() and unknown OIDs

John Dennis
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: CERT_AsciiToName() and unknown OIDs

Miklos Vajna
Hi,

On Thu, Feb 23, 2017 at 10:44:10AM -0500, John Dennis <[hidden email]> wrote:
> You should follow the RFC specifications, in this case RFC-4514 and
> RFC-4512.

Thanks for the numbers, I wasn't sure where is this specified.

> 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.

Should I file a bug at <https://bugzilla.mozilla.org/> about this?

Regards,

Miklos
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: CERT_AsciiToName() and unknown OIDs

John Dennis
On 02/23/2017 11:38 AM, Miklos Vajna wrote:

> Hi,
>
> On Thu, Feb 23, 2017 at 10:44:10AM -0500, John Dennis <[hidden email]> wrote:
>> You should follow the RFC specifications, in this case RFC-4514 and
>> RFC-4512.
>
> Thanks for the numbers, I wasn't sure where is this specified.
>
>> 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.
>
> Should I file a bug at <https://bugzilla.mozilla.org/> about this?

Yes


--
John
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: CERT_AsciiToName() and unknown OIDs

Miklos Vajna
Hi,

On Thu, Feb 23, 2017 at 11:59:28AM -0500, John Dennis <[hidden email]> wrote:

> >>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.
> >
> >Should I file a bug at <https://bugzilla.mozilla.org/> about this?
>
> Yes

OK, submitted as <https://bugzilla.mozilla.org/show_bug.cgi?id=1342137>.
Thanks in advance for whoever can look at it. :-)

Regards,

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