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 20:16:34 -0400
To: "Yngve N. Pettersen" <yngve@opera.com>
Cc: pbaker@verisign.com, public-wsc-wg@w3.org
Message-ID: <20070729001634.GX2974@raktajino.does-not-exist.org>

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?

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?

I'm having a sense that your e-mail lists a bunch of significant
technical work that needs to be done to make sense of EV
certificates...

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





On 2007-07-28 19:10:16 -0500, Yngve N. Pettersen wrote:
> From: "Yngve N. Pettersen" <yngve@opera.com>
> To: Thomas Roessler <tlr@w3.org>, pbaker@verisign.com
> Cc: public-wsc-wg@w3.org
> Date: Sat, 28 Jul 2007 19:10:16 -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
> 
>
> Thomas,
>
> A point here is that having an OID does not, by itself, indicate that the 
> certificate is issued according to the EV guidelines.
>
> There are several requirements that must be in place before a client can 
> indicate that the certificate is an EV certificate:
>
>  1. The CA must pass the EV compliance audit
>  2. The OID indicates that the certificate itself has been vetted according 
> to the guidelines
>  3. There must be an agreement between the issuer and the client vendor, 
> that the client accepts the issuer's OID as a an EV indication.
>  4. That information must be distributed to all clients from the vendor.
>
> Only when all these are in place can the EV OID be considered to indicate EV 
> status.
>
> Considering these requirements, having a single standardized OID, or 
> multiple OIDs, is not really that important.
>
> A standardized OID will (almost) "only" make it easier to tell it is an 
> alleged EV cert, and before you could say it really is an EV cert you would 
> need access to the most recent EV audit and make your decision based on that 
> audit. Deployment from the client vendor is fractionally easier, but not 
> (IMO) significantly so.
>
> Another thing is that the EV-OID for a Root CA must be revoked if the Root 
> CA fails an audit.
>
> Actually, it is my opionion (The root CAs may disagree) that each sub-CA 
> issuing from a root should be assigned an individual OID, making it possible 
> for a Root CA to inform clients that a particular EV OID for a given sub-CA 
> is no longer to be accepted as an EV indication, without affecting any other 
> sub-CA's EV status. The primary drawback of this method could be logistics, 
> but I do not think it would be unsurmountable.
>
> Given all this, multiple OIDs or a single OID-arc is probably a coin toss.
>
> On Sat, 28 Jul 2007 14:20:18 -0500, Thomas Roessler <tlr@w3.org> wrote:
>
>>
>> Phill,
>>
>> I see that your current conformance language for EV certs includes
>> the following phrase:
>>
>>   A certificate issuer distinguishes a certificate authenticated
>>   according to EV criteria by means of an issuer specific extension
>>   OID.
>>
>> --  http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/EVCerts
>>
>> I'm not sure if it's just me, but I'd like to see a specific OID
>> with a normative reference to an open standard in that place.  The
>> current language is effectively a hook for all kinds of proprietary
>> material, and indeed not enough to usefully assess any kind of
>> interoperability or compliance.
>>
>> Maybe the definition of that OID is worth a two-page RFC, to be done
>> in PKIX reasonably quickly?  (Despite having sat in the meeting last
>> week, I'll admit ignorance as to the politics of PKIX and the
>> group's ability to do things like that quickly.)
>>
>> Cheers,
>
>
>
> -- 
> 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:16:42 GMT

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