Re: dsaWithSHA1_PKIX oid(1.2.840.10040.4.3)

David Brownell (David.Brownell@Eng)
Tue, 27 Jan 1998 18:10:10 -0800

Date: Tue, 27 Jan 1998 18:10:10 -0800
From: David.Brownell@Eng (David Brownell)
Message-Id: <199801280210.SAA08907@argon.eng.sun.com>
To: java-security@web2.javasoft.com, wessorh@ar.com
Subject: Re: dsaWithSHA1_PKIX oid(1.2.840.10040.4.3)

> why does java1.2beta2 create DSA/SHA1 x509 Certs with this
> as an algorithm ID. This OID makes SSLea and many other
> SSLv3 based apps dump core.

Well, that'd be a bug in those apps! Coredumps aren't OK, ever.

> Who owns the 1.2.840.10040 part of the oid tree? sun?

This was the OID specified by the IETF PKIX group. They changed their
OID several times; this is the "final" one. You'll note that the TLS
spec requires conforming to PKIX for OIDs and stuff. I think that part
of the namespace is controlled by ANSI X.9 ... see:

ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-06.txt

On page 53 (!) it defines:

id-dsa-with-sha1 ID ::= {
iso(1) member-body(2) us(840) x9-57 (10040)
x9cm(4) 3 }

> why don't you want to make the certs with 1.3.14.3.2.27?
> more things understand this OID.

In fact, I've yet to see anything using that OID. I've usually
seen the DSA OID specified to be 1.3.14.3.2.13 ... evidently NIST
accentuated early confusion by assigning a second oid for DSA! I
suspect it's because the "13" OID was assigned using a "proposed
FIPS" (in the 1994 NIST 'stable implementors agreements') and for
some reason at least one implementor didn't want to delete support
for the final standard (final ones normally supercede drafts).

- Dave

> thanks,
>
> -rick (hacking SSLea so that it understands your OIDs)
>
>
>
>
>
>