375666 - Need function that provides a cert's Extended Validation (EV) status

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[Kai Engert [:KaiE:]]

Extended Validation (EV) certificates are supposed to be a new class of cert ownership identity verification.

NSS should implement a public function that applications can call, in order to obtain the answer to the question:

  "Is the given certificate a valid EV certificate?"

The function signature could look like this, initial proposal:
SECStatus CERT_IsValidExtendedValidationCert(CERTCertificate *aCert);

This bug shall track the availability of the new function.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

How is this related to bug 374336?

Comment 2

[Kai Engert [:KaiE:]]

This bug blocks bug 374336.

This bug is meant to provide the base functionality in the cross-application C library NSS.

Bug 374336 talks about PSM and should be used to add Mozilla client application level handling of EV certs like UI.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

I'm not convinced that this functionality belongs in NSS.  
I believe it is not of general interest to NSS-based products other 
than the browsers.  
I propose that this function be supplied by PSM.

The libPKIX project for NSS (planned for NSS 3.12) will deliver the ability
to so a *standard* check of a cert chain, including policy OIDs.  However,
the the EV check (as proposed) requires an additional non-standard policy 
OID check, to ensure that the policy OID used in an EV cert is one that 
is known to belong to the root CA to which the chain is anchored.  This 
requires storage of one or more policy OIDs for each root CA cert.  
The storage of this information is outside of any known standard, so 
standard interfaces are not likely to carry that info.  

I believe that EV ceret checking can be accomplished with the following steps:

1. DO a standard PKIX validity check on the cert chain.  One of the outputs
of that check is a list of valid policy OIDs allowed/supported by that chain.
(This can be done with NSS when libPKIX is in place).  Then,

2. Do an additional check to see which (if any) of the policy OIDs obtained in 
step 1 is an EV policy OID belonging to the root CA that anchors the chain.
That check could be done by PSM, IMO.

Finally, note that there are NO UI aspects to this bug/RFE, although there
probably are some associated with bug 374336.

Comment 4

[Kai Engert [:KaiE:]]

If I understand correctly, the current thinking is:
- NSS shall provide all required helper functions that enable an 
  application to make decisions about validity of certs and their policies
- NSS shall not carry the knowledge about EV policies on its own
- therefore NSS can not draw conclusions about the EV status
  of a given cert.

It shall be the responsibility of the client application's code (PSM) to store knowledge about "Roots and OIDs approved by Mozilla.org for EV" (assuming that will happen at some point) and draw conclusions about the EV status of certs.

I'm therefore resolving this as WONTFIX.