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

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 UTC