W3C home > Mailing lists > Public > public-wsc-wg@w3.org > July 2007

Re: EV-cert: "issuer-specific extension OID"?!

From: Thomas Roessler <tlr@w3.org>
Date: Sat, 28 Jul 2007 21:38:57 -0400
To: "Yngve N. Pettersen" <yngve@opera.com>
Cc: pbaker@verisign.com, public-wsc-wg@w3.org
Message-ID: <20070729013857.GY2974@raktajino.does-not-exist.org>

In other words, we're not dealing with a machine-readable property
of trust anchors, but with an property essentially signalled
out-of-band.

Doesn't strike me as particularly scalable, and I suspect Stephen
will have comments on Monday. :)

-- 
Thomas Roessler, W3C  <tlr@w3.org>






On 2007-07-28 19:48:02 -0500, Yngve N. Pettersen wrote:
> From: "Yngve N. Pettersen" <yngve@opera.com>
> To: Thomas Roessler <tlr@w3.org>
> Cc: pbaker@verisign.com, public-wsc-wg@w3.org
> Date: Sat, 28 Jul 2007 19:48:02 -0500
> Subject: Re: EV-cert: "issuer-specific extension OID"?!
> X-Spam-Level: 
> Organization: Opera Software ASA
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 
> 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 01:47:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:50 GMT