RE: Minor OID mistakes in OCSPv2 and the official OID list

["Michael Myers" <[e-mail]>]

On Saturday, May 19, 2001, at the inspiring hour of 3:30 AM, Peter Gutman
advised:

> Given that there are already certs (and lots of software)
> out there which use the current OID, wouldn't it be better
> to relocate temporalDataAuthority (what is that anyway?
> Does anyone use it? It looks like an oddly-named TSA OID).
>
> (Given that the OCSP OID is already in active use, I suspect
> {id-kp 9} will remain "the OCSP OID" even if it's officially
>  reassigned, this my comment that it's going to be easier for
> Mohammed to go to the mountain).
>
> Peter.

Peter,

Certainly a more pragmatic approach.  As a consequence I've spent some time
today searching across the various current and historical IETF work products
to do kind of an environmental impact assessment of simply re-labelling
{id-kp 9} from "id-kp-temporalDataAuthority" to "id-kp-OCSPSigning".

As it turns out, the notion of a Temporal Data Authority (TDA) and a
corresponding {id-kp 9} definition was introduced at least by
http://www.ietf.org/proceedings/99jul/I-D/draft-ietf-pkix-time-stamp-02.txt.
However, by the -14 edition the concept went away:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-14.txt.

So the path seems clear to redefine {id-kp 9} as id-kp-OCSPSigning with no
impact to timestamping implementors.  Doing so would benefit standing OCSP
implementations but does not excuse the OCSP authors, myself included, from
a swift kick in the butt for failing to coordinate across the WG on this
point.

Incidentally, it might be useful to produce the relevant OID list into a
PKIX work product so that once PKIX wraps clues are left behind how the
pieces are supposed to bolt together.

Mike


Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com