- From: Yngve N. Pettersen <yngve@opera.com>
- Date: Sat, 28 Jul 2007 19:48:02 -0500
- To: "Thomas Roessler" <tlr@w3.org>
- Cc: pbaker@verisign.com, public-wsc-wg@w3.org
On Sat, 28 Jul 2007 19:16:34 -0500, Thomas Roessler <tlr@w3.org> wrote: > The revocation requirement that you raise (and the way it maps to > different OIDs) is interesting. Are there any specifications under > development that would provide for an OID-based revocation protocol? The revocation would be done out of band, between the root CA and the vendor, then the vendor would distribute it to deployed clients through some update mechanism. Additionally, if the Root CA falls out of compliance (for whatever reason) the vendor would do the same. The update mechanisms are established by the vendors, and IMO does not need to be standardized. The same applies to the communication between the vendor and the Root CA. > Is there any guidance as part of the EV material (I'll admit that I > still haven't read the CABforum papers in detail) that would include > your "distinct OIDs" requirement? No, the only requirement is to have an OID in the subsciber certificate that is recognized by the client, and a policy filter in the intermediate CAs. There is an obvious minimum of one OID, there is no maximum. My suggestion may be considered a bit "better safe than sorry", in case a renegade sub CA turns out to be untractable. Essentially though, the requirement to check CRLs for intermediate CAs takes care of most of the issue. I do expect, however, that each CA will use another OID to indicate compliance with a significantly modified specification, if/when such a specification is needed. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ********************************************************************
Received on Sunday, 29 July 2007 00:48:25 UTC