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

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 May 2001 19:20:17 +0200 (MET DST)

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

I support Peter's view, the kp 9 is in a standards track RFC (2560), 
and the only definition of TDA is in an expired draft of timestamping, 
and this data is already obsolete.   

Also 2459 stops at kp 8 and even the new draft.

C.4. Identification of the TDA

The TDA MUST sign all temporal data tokens with a key reserved 
specifically for that purpose.  The corresponding certificate MUST 
contain the extended key usage field extension as defined in [RFC2459] 
Section 4.2.1.14 with KeyPurposeID having value 
id-kp-temporalDataAuthority.  This extension MUST be critical.

id-kp-temporalDataAuthority    OBJECT IDENTIFIER ::= {id-kp  9}
  -- Providing temporal data in support of time stamping services.  Key 
  -- usage bits that may be consistent:  digitalSignature, 
  -- nonRepudiation

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 18 May 2001 12:03:35 -0700

Michael --

A number of existing OCSP client and server implementations (CA, ValiCert,
Kyberpass, etc) already use id-kp-OCSPSigning {id-kp 9} any changes to this
would certainly break a number of production systems. I am unsure what the
id-kp-temporalDataAuthority is used for or how broadly it is used but before
we formally change id-kp-OCSPSigning we need to explore which will effect
existing systems the least.

Ryan M. Hurst
Manager Solutions Engineering
ValiCert, Inc.
-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Thursday, May 17, 2001 5:56 PM
To: Jeff Jacoby; [email-masked]
Subject: RE: Minor OID mistakes in OCSPv2 and the official OID list

Jeff,

Thanks for the catch.  Yes, clearly the OID {id-kp 9} was assigned to
id-kp-temporalDataAuthority for EKU.  In coordination with the PKIX OID
Registrar and the IESG, we will correct this defect with the result of a new
OID for id-kp-OCSPSigning for use in EKU.

BTW, are you and/or your interoperability partners facing a need that
depends upon this feature?

Mike

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 18 May 2001 11:39:23 -0700

I agree (with Peter).

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 18, 2001 8:30 PM
> To: [email-masked]; [email-masked]; [email-masked]
> "Michael Myers" <[email-masked]> writes:
> 
> >Thanks for the catch.  Yes, clearly the OID {id-kp 9} was 
> assigned to id-kp-
> >temporalDataAuthority for EKU.  In coordination with the 
> PKIX OID Registrar
> >and the IESG, we will correct this defect with the result of 
> a new OID for id-
> >kp-OCSPSigning for use in EKU.
> 
> (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.
>