Subject: RE: cA flag and CRL issuers

From: Peter Williams <[email-masked]>
Date: Thu, 24 May 2001 14:59:02 -0700

"And does an AA have ability to enforce this delegation (via key usage 
flags, etc) in parallel to the mechanisms afforded a PKC-CA?"

PMI AAs have a properly designed set of delegation techniques
to accomplish this and other uses of delegation that control
privileges; this set contrasts markedly with the proposed
kludges for PKI entities. 

The functions of AA-based delegation are properly modelled as 
privileges,  specified for us to use, and our implementable. They
do not rely upon misuing (or even require the
existance of) of PKI extension fields to enforce
the Housley "authority policy" [X.509], say, between an issuing
authority and a CRL issuer. 

X.509 certainly does not require that a CRL Issuer be issued a 
PKI cert by the CA with whom it cooperates in the matter of
communicating revocation notices, or require that the
authority that does issue indirect CRLs be in the
same certification/policy domain as the cert issuing authority.

Indeed, I dont know how anyone can read X.509 and claim
that it mandates or even describes a delegation
model between  CAs and CRL Issuers. It specifically
states that "authority policy" [X.509] deals with these
kind of matters, particularly when there are multiple
CRL Issuers for a given CA.  The PKI work in X.509 simply does not 
require nor does it describe the use of delegation as 
an enforcement technique, and it does not mandate/hint/intend
any particular authority policy.

If PKIX authors want to mandate an authority policy (why? I 
understand why MISSI users would want a uniform policy, but why 
so constrain the Internet PKI?) then they should do it properly using the 
techniques provided. Use PMI delegation privileges, using the delegation 
model in 15.5, constraining the certificate policy oids in the CRL 
Issuers EE cert so relying parties can use conventional cert path processing

to enforce the CAs authority policy over the CRL Issuers. 

This way (15.5.2.3), bridge models, hierarhical
models and cross-certification models all still work; hierarchical
PKIs can still use CRL issuers in bridge models, etc, by using
policy mapping, path processing enforcement, etc.

Peter.

---

From: Peter Williams <[email-masked]>
Date: Tue, 29 May 2001 13:28:40 -0700

Tony and Bob:

Based on elements of my doctoral investigations in
1992/3, in 1997 I penned chapter 12 "secure electronic commerce"
of a book I co-authored with others: "Digital Certificates".
That chapter expounds a doctrine of relying-party trust; my aim
was to make readers think about the design options when profiling; 
PKIX provided little rationalization for its design decisions, and
has always lacked sensitivity to commercial credentialing practices. You
can read about similar issues in Tom Austin's book on PKI, in
my view. These profiling themes contrast markedly with the scholarly
doctrine reflected in the books of Housley, Adams, etc., which
would have you believe that Internet PKI was (a) a single camp of thought
reflected in PKIX docs, and (b) you, the Internet end-consumer, are, 
quite properly, just a robotic subscriber.

The main reason I left (1997-style) verisign for valicert was because the
latter's business model (1998) focussed on a (modernised) method for
bridging 
the competing goals of mandatory and discretionary security policy 
enforcement. given hindsight I'd now write the afore-mentioned chapter quite

differently, for a 2002 audience given actual infrastructure deployment 
events since 1998. The current issues of CA bit (like the NR bit) are the 
manifestation of the quite principled but very different security policy 
philosophies present within our user and design communities, in my view.

Despite my reservations, I do think we need to finish 2459+ Final Call, and 
respect the hard work that the tightly-nit PKIX author and advisor group
have 
put in. Im not  sure its the standard that reflects the WG, or the needs of
the Internet 
enviroment. But, it does act as the snapshot lynchpin, that makes the 
document set reasonably consistent and coherent, for this point in time. 
We should ensure we consolidate this fine technical achievement, even
if security policy matters will need further standardization at another
time, or in another forum that cares less about trusted keys and more
about trusted interworking.

Postcript:

It will be interesting to see what the authors in
http://www.amazon.com/exec/obidos/ASIN/0850926602/qid=991167837/sr=1-3/ref=s
c_b_3/107-6570836-8267712
have to say on infrastructure thenes, as reflection of a large (US) 
govt's position when delivering services via the Internet.

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]]
Sent: Tuesday, May 29, 2001 12:14 PM
To: Bob Jueneman; [email-masked]
Cc: [email-masked]
Subject: RE: cA flag and CRL issuers

Bob,

I echo your sentiments.

A certificate is fundamentally a statement by something called a CA, that 
says, "We stand behind the associations embodied in this certificate until 
we say otherwise (or it expires naturally.)"

The fact that they made such an assertion, one way or another, is just one 
piece of data in a relying party's particular trust model.  The RP may 
either desire to "revoke trust" in that certificate, despite a CA's lack of 
revocation, or may have reason to wish to continue relying upon a 
certificate even though the issuing CA has revoked it.

It is the Relying Party that Relies.  All others are simply factors in the 
RP's trust calculation.

And a rational PKI profile would recognize this fact and provide 
corresponding guidance so that end-user products support user ease and 
flexibility in local trust management.

___tony___

At 11:28 AM 5/29/01 -0600, Bob Jueneman wrote:
>Michael,
>
>I commented on this earlier, but no one picked up on it.  Maybe it got 
>lost in the noise.
>
>Generally, I would agree with you.  However, the entire purpose of PKI is 
>to serve the needs of the relying party, first and foremost.  And since 
>the most cases the relying party is a member of an organization that may 
>wish to impose some collective rules for processing certificates, I 
>believe that necessitates the ability to have the option for LOCAL control 
>over CRLs and OCSP responses.
>
>Since in the general the subscriber or issuing CA may not even know who 
>the relying parties may be, this means in particular that it is NOT always 
>possible, nor desirable to require that the source of a CRL must 
>necessarily be named in advance, for example in a CRLDistributionPoint, or 
>signed or otherwise anointed by the CA, for that would turn the relying 
>party trust model on its head.
>
>So I would rephrase your requirement to state that the provenance of a 
>certificate, including its current validity and trust status or lack 
>thereof, must link back in a technical fashion to a trust root installed 
>in the relying party's software.  Assuming that the CA's, AA's, etc., root 
>is installed the RP software, your requirement is a proper subset of what 
>I am proposing.
>
>"Is there anyone else thinking same way, or am I unique in this
perspective?"
>
>Bob
>
>Robert R. Jueneman
>Security Architect
>
>Novell, Inc -- the leading provider of Net services software
>
>
>
> >>> "Michael Myers" <[email-masked]> 05/29/01 11:07AM >>>
>All,
>
>Regarding this thread, it seems to me that whether setting the cA bit for
PK
>certs, establishing algorithmic logic regarding naming or authorizations,
>maybe in the long run inventing a cA bit equivalent for ACs or whatever
>other technical mechanism we may devise, there exists a meta-requirement
>that the provenance of a digital credential MUST link back in a technical
>fashion to the source of its original issuance.  Is anyone else thinking
the
>same way or am I unique in this perspective?
>
>Mike
>
>
>Michael Myers
>t: +415.819.1362
>e: mailto:[email-masked]
>w: http://www.traceroutesecurity.com

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: "Bob Jueneman" <[email-masked]>
Date: Tue, 29 May 2001 15:31:12 -0600

David,

Please see my comments in-line.
>
>>>> "David P. Kemp" <[email-masked]> 05/29/01 02:08PM >>>
>A Relying Party has the ability to control which CAs it trusts to issue
>certificates, and it also has the option of trusting public keys for which
>no CA has issued a certificate.  It likewise, as you say, has the option of
>accepting a certification which has expired or been revoked by its issuer,
>or refusing to accept, on a case-by-case basis, a certification which has
>not expired or been revoked.

OK, so we are at least agreed in principle regarding the question of managing trust from the RP's perspective.
>
>But despite the fact that the Relying Party is always in control of what
>that RP chooses to accept from others, RP applications need a specification
>(the PKIX profile) that tells how to reliably determine what the issuer of
>a certificate thinks about that certificate's current status.

I would certainly agree that what the issuer thinks is at least relevant.  And if the issuer says that it is revoked for cause (as opposed to merely expired, or perhaps a trivial address update), then if I were the RP or the determining organization, I would certainly think long an hard before continuing to trust it.

However, the CA should not have an equal vote in the matter if the CA knows of no reason why the certificate should not be trusted but the RP does, (or for that matter even some other credible party, such as a state registration agency or licensing authority, as provided for under a number of state and foreign country's laws.)
>
>** No one but the issuer can revoke that issuer's certification. **

Well, that is precisely the disagreement, isn't it?  Or let me clarify that just a bit.  What I care about is revoking the certificate itself.  Revoking the issuer's certification of that certificate is a slight, but perhaps a significant nuance of difference.
>
>You may wish to use the X.509 CertificateList data structure to contain
>some other authority's opinion of a certificate, or of the subject of
>that certificate.  That's fine, but you can't call it a CRL or process
>it using the PKIX path validation algorithm.

And just why not?  Did I miss that particular tablet of stone somewhere?  I thought that was what we were debating.

I'm always willing to consider other, alternative means of achieving any particular objective, so long as they are reasonably well standardized and widely implemented on commercial software packages.  But if I were the RP's organization, I would certainly NOT like to have to throw out all of my browsers, my S/MIME software, etc., just to achieve this objective -- that's a non-starter.

As someone else said, I don't care whether we call this a CRL, or an RPCRL, or a french fry, so long as it works.  But saying ipso facto that this mechanism cannot be processed using the {PKIX path validation algorithm would seem to be jumping to a conclusion, since that was the question at hand.

In particular, merely putting a certificate in some kind of a blackballed data structure, as I think you are proposing (I'm putting words in your mouth, so correct me if I am wrong), would probably NOT be sufficient, and especially from a nonrepudiation standpoint, because as I understand it those certificate structures would not be cryptographically bound to a reliable source.  And even though it would be the RP's organization that would presumably post this particular french fry, it still seems worth providing a nonrepudiable binding mechanism.

So from the standpoint of minimizing development cost and maximizing interoperability, processing a local revocation of a certificate via the PKIX path validation algorithm is PRECISELY what I would like to do.  

Bob

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 30 May 2001 10:10:03 -0400

Bob Jueneman wrote:

> >
> > [dpk] ** No one but the issuer can revoke that issuer's certification. **
> 
> Well, that is precisely the disagreement, isn't it?  Or let me clarify that
> just a bit.  What I care about is revoking the certificate itself.
> Revoking the issuer's certification of that certificate is a slight,
> but perhaps a significant nuance of difference.

My statement was a bit terse, and I certainly see how it could be interpreted,
not as intended, but as a stone-tablet pronouncement.

The issuer has signed a statement binding name to key, and only the issuer,
from the standpoint of Noah Webster (as opposed to the standpoint of Moses)
is able to state that in the eyes of the issuer that binding is no longer
in effect.

There are three cases to consider:

1) The CA can revoke certificates using its own signing key directly, or
indirectly by signing a cRLSign certificate, an Authorized OCSP responder
certificate, or an EE cert with a CRLDP referring to an ICRLA.

2) A revocation authority could stand up on its own, with no blessing from
a CA, but claim that it will faithfully reflect the CA's revocation status
to the best of its ability.  This is the Trusted OCSP responder model.

3) An authority stands up on its own with no CA blessing, and overtly claims
that it will not reflect the CA's revocation status, but instead will reflect
some local policy such as an employee's right to access company assets.

By dictionary and common sense, #3 is not a "Certificate Revocation List",
it is an "Access Control List".  You and Tony argue that it is a good idea
to mix authentication and access control because such mixing is expedient --
products support revocation of authentication credentials but do not widely
support access control.  You further argue that the PKIX path validation
algorithm should be modified to officially sanction the merging of
authentication and access control.

I argue that such merging (done unofficially) is a bad idea from a security
point of view, and it would be an even worse idea to modify X.509 and
PKIX to officially support non-CA-authorized CRL signers.

> I'm always willing to consider other, alternative means of achieving
> any particular objective, so long as they are reasonably well standardized
> and widely implemented on commercial software packages.  But if I were the
> RP's organization, I would certainly NOT like to have to throw out all of
> my browsers, my S/MIME software, etc., just to achieve this objective --
> that's a non-starter.

I can think of three off the bat:

1) Request that the CA issue an "authorized revocation authority" (OCSP or
ICRLA)
   certificate to your local status authority.  This is expedient (in the
   pejorative sense) and the CA might refuse to do it, but it requires no
   undesirable changes to the text of X.509 or to products.

2) Stand up a CA which explicitly issues certificates according to local
   policies such as employment status, and then revokes those certificates
   according to the same criteria under which they were issued.  This does
   no violence to the intent of X.509, and requires no changes to products.

3) Use a "trusted OCSP" responder and forget about CRLs.  I think this
   option should be deprecated, but it is documented today in RFC 2560.

4) A fourth option, which of course requires better products, is to
   use a proper PMI.  The PMI standards are there; it's up to product
   developers to determine if there is a market.

I'm not persuaded by "well, products haven't seen fit to support authorization
yet, so let's muck with the authentication standard to support coarse-grained
(yes/no) bastardized privilege management."

Regards,
Dave

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 30 May 2001 11:35:55 -0600

Dave, thanks for the clarification.  For a while there I was afraid I was going to have to appeal to Charleton Heston!

I agree that semantically, only the issuer can revoke the issuer's binding of a key to whatever else may be contained in the certificate, normally the identity of the holder of that key, and state, as you say, that in the eyes of the issuer, that binding is no long in effect.

But you then jumped from notion of certificate revocation, or what might more accurately be called certificate trust revocation, to the notion of access control and PMI.  I don't equate the two, although of course there is some overlap.  So I don't agree that your case #3 isn't a CRL, but rather access control, or PMI.

Instead, I want to use some form of certificate revocation or whatever we call it to revoke encryption certificates for various recipients, and to revoke digital signature certificates for people I no longer trust to sign documents or transactions.

I suppose you could argue that if X.509 PKI is exclusively about identity, then there is some justification for claiming that the CA is reasonably authoritative for identity and thus only the CA should be able to revoke the trust relationship inherent in the certificate -- the end-entity presumably hasn't been transmogrified into someone else, and even if they were, they are presumably still responsible for their actions.

But we all know by now, I hope, that the initial naive "nonrepudiation" conceit of the technologists (and I include myself there) that if we could just be sure who someone really was, that the world would be a much better place, simply hasn't materialized.  We handed the car dealer our driver's license and drove off in the Ferrari on a test drive, and never returned.  Even if the driver's license wasn't falsified, what are you going to do next -- send the sheriff into cyberspace to arrest some e-mail name? In fact, putting aside religious arguments about ASN.1 vs. "simpler" mechanisms, the SPKI crowd probably had it closer to right than the PKI crowd, because the essence of a workable PKI isn't just identity, but authority and credibility, i.e., trust.  Remember, the original use of X.509 was to authenticate an individual to a directory, where such decisions could be made. but we effectively threw away the directory, and proposed making decision based on the certificate itself!
, with no other information.

That's why there have been virtually no Residential Person certificates issued to speak of  -- only Organizational Person certs -- because rightly or wrongly, the implicit affiliation of the individual with an organization carries a lot of weight, to the point that the name almost doesn't matter an most cases. (I said almost. :-)  and hence there is little or not acceptance of a Residential person certificate, except perhaps for casual e-mail encryption.

I note that the current specification allows an independent OCSP responder to comment on the status of a certificate, and indirectly on the trust associated with the end-user.  You deprecate that usage, but there it is.  So why does the certificate validation concept depend on the choice of protocols?  We should be arguing philosophy, not protocols and whether or not the certificate is checked in real time.

You argue that "such merging (done unofficially) is a bad idea from a security point of view, and it would be an even worse idea to modify X.509 and PKIX to officially support non-CA-authorized CRL signers."

Particularly if the "merging" is local to a single relying party's organization, I would like to better understand your reasoning as to why you think that is a bad idea, for that certainly isn't obvious to me.  Instead, I believe that continuing the rely on the CA's potentially out of date world view, when that CA has no obligation to continuing monitor the trust relationship associated with that user, is in fact the Bad Idea, if relied on exclusively.  The CA is only obligated to revoke a certificate upon the request of the end-user, who may have every interest in the world to continue to use that certificate.  That simply isn't good enough for all situations.

Likewise, I disagree with the assertion that it would be an even worse idea to modify X.509 and PKIX to officially support non-CA-authorized CRL signers.  Local RP organizational control is one such case that makes eminently good sense to me, as does the notion of some overarching authority such as a State or Federal CA licensing authority, for example.  And if we get into Attribute Certificates, or attributes within a certificate that reflect a credential such as whether or not someone is a medical doctor (that's an attribute, not a privilege, although the RP may decide to confer a privilege based on that attribute), then I think having a non-CA such as the state medical association be able to revoke such credentials is even more important.

The issue of whether products do, or should support PMI is a separate issue.  They don't, and they should, but in my view, at least, that still doesn't solve the trust problem.  And we are ten years and counting.

Regards,

Bob

>>> "David P. Kemp" <[email-masked]> 05/30/01 08:10AM >>>

Regards,
Dave

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 31 May 2001 14:36:16 -0600

Russ, 

The more that I think about it, the more I believe that what Tony and I (and Peter Williams) are getting at is the difference between a rather blind syntactic validation of a certificate chain, including the binding between the certificate contents and the public key by the issuer's signature, vs. the somewhat more amorphous notion of "trust" -- not of the certificate, but of the designated entity.

As Steve correctly points out, although "trust" is a rather slippery concept, it is unavoidable, at least with respect to the CA.  Whatever it means, and that is really and finally in the eye of the beholder, i.e., the relying party, if you don't "trust" the CA, you certainly shouldn't include their root in your browser's list of trusted roots. 

But why should this be so?  After all, whether they would admit it or not, Microsoft and Netscape serve very well as de facto global CAs by including a collection of CA roots in their browsers.  And I believe that code is signed, as well.  So presumably there isn't any question as to whether those roots are syntactically valid or not, and their CPS is effectively embedded in their click-wrapped contract which you have to accept before installing the product.

Well, one possible reason for rejecting some CA's certificate is that you don't like, trust, or agree with the due diligence that CA has decided to provide, or maybe you don't feel comfortable with the digital signature statutes of Afghanistan or Zambia, or the state-run CA of Iraq, or the Mafia.  So despite the fact that there is no disagreement that the name of the CA has been accurately conveyed with appropriate due diligence, or that the public key (and hence the private key, indirectly) has been properly bound to that name and not compromised or revoked, nonetheless we don't choose to accept that CA's certificate.

But isn't this inconsistent with the "identity is all that matters" PKI philosophy some would espouse?

If you agree that there are circumstances where you as the relying party might choose not to trust a CA, despite the fact that all of the circumstances of the signature chain are in order, then why shouldn't the same logic apply to an end user, someone who is much more likely to cause me some harm than the CA is?  It really shouldn't matter why I choose not to trust that individual -- maybe he is gay, or a Boy Scout, or a red-head, or an Iraqi terrorist; or all of the above -- I simply choose to trust him, or to accept his credentials. (And to disagree with Steve on one point, this has nothing to do with nonrepudiation.)  

But t answer your question, just because I choose not to trust some entity, or their certificate, or the horse they rode in on, doesn't mean that their certificate is suddenly invalid from a global perspective, or that someone else might quite legitimately continue to trust the entity.  And so I have very little cause to even ask the CA to revoke the certificate, and certainly no way to compel the CA to do so.  And it wouldn't be right.

That view is consistent with not accepting a CA's certificate in a browser, and it is also consistent with the local policy control mechanism which has already been accepted in RFC in the case of OCSP.  So it is really the CRL path validation mechanism that we are treating inconsistently.

Now, I will certainly grant that there would be other ways to control the acceptance of a certificate, other than the CRL mechanism.  I could certainly add that certificate to a directory of blackballed certificates.  But the question is, who would use such a mechanism?  As a single end-user enterprise, I certainly can't afford to go off and rewrite all of the browsers, SSL, and S/MIME code I have lying around, not to mention  Adobe Acrobat, a number of forms processors, B2B transaction processors, etc.  It is simply too huge a job.  And even if I could somehow cajole one vendor into doing it, that doesn't solve the problem -- I need EVERYONE to do it with one uniform mechanism, or the system is still broken.

Maybe I'm missing a technical nuance or "gotcha" somewhere, but I continue to believe that a local CRL chain that is tied back to a trusted root in the browser, i.e., my own Enterprise's certificate, solves these problems almost automatically, and with little if any changes required to existing code.

If that simply can't be made to work without upsetting the apple cart, then I suppose we (or the RP) could jettison support for CRLs entirely and just use OCSP, but that seems both inconsistent from a standards perspective and undesirable from a performance standpoint in some cases.

Regards,

Bob

>>> "Housley, Russ" <[email-masked]> 05/31/01 08:47AM >>>
Tony:

If YourOrg decides that a particular UserNameN and UserKeyN that was 
certified by WhoeverCA, they can do so.  PKIX does not (and I think should 
not) have a standard mechanism to do so.  If YourOrg feels that one 
certificate issued by WhoeverCA should be revoked, and WhoeverCA has 
not/will not revoke it, then why would YourOrg continue to trust WhoeverCA 
for any certificates?  It seems to me that the WhoeverCA certificate should 
be revoked or removed from the certificate trust list.

Russ

At 11:43 AM 5/30/2001 -0700, Tony Bartoletti wrote:
>At 10:10 AM 5/30/01 -0400, you wrote:
>Dave,
>I agree that mixing (identity) authentication and authorization is bad 
>(however expedient.)
>
>My issue, perhaps academic, was not one of authorization.  I intend that 
>the RP (or RP organization) unilaterally declares that binding of identity 
>(DN) to key is voided.  The net result might not be the same regarding 
>authorization.  If an "identity" binding fails, there may be myriad 
>separate authorizations the need to be revoked, but only the one name-key 
>binding.
>
>I argue the RP has a right to declare the CA-issued certificate to be 
>"null and void", and to be able to promote this declaration throughout the 
>organization.
>
>Perhaps this "should" be accomplished by having the RP-organization-as-CA 
>issue its own certification for every public key of possible interest, in 
>which case it could revoke according to the present mechanisms, and 
>everything "works".  To ensure that third-party certifications are (by 
>default) untrusted, it would need to purge the vendor-installed default 
>root certificates from its systems.
>
>___tony___
>
>
>
>
>___tony___
>
>
>

---

From: Peter Williams <[email-masked]>
Date: Thu, 31 May 2001 17:48:21 -0700

I think this was very good news.

Let me put Steve's apparent statements in simpler, declarative form
in which each numbered assertion is a self-contained truth devoid
of context, other than perhaps assuming the truth of an earlier 
numbered assertion:

1. OCSP can be used in side-effect modes.

2. It is legitimate to use OCSP responder working in a
side effect mode to achieve the goals T&B cite

3. You can "rely" on an OCSP responder/response.

4. You can combine an OCSP side effect mode with reliance
on an OCSP responder/respose.

5. A relying party can rely upon an OCSP responder working
in side effect mode "V" as "a local means of asserting per-certificate
validity
judgements that might override those of the CA who issued a cert."

6. To use and rely on an OCSP responder operating in side effect
mode "V" is to be operating in a manner compatible with the PKIX
overall model.

7. The same general theory holds for a DPV server.

Do you agree that some or all of my numbered assertions are consistent
with Steve's message, as you intepreted it?

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, May 30, 2001 7:24 PM
To: Tony Bartoletti
Cc: [email-masked]
Subject: Re: cA flag and CRL issuers

Tony & Bob,

This discussion re revocation seems to be colored by excessive use of
the term "trust."  It's common to use that term in discussing PKIs,
and the public CA approach to PKI, exemplified by VeriSIgn,
encourages that notion, because such CA are viable only if "trusted."

However, that is not the only way to think about roles in a PKI.  If
CAs are aligned with physical world entities that are authoritative
for the data contained in certs, e.g., companies issuing certs for
employees, then these CAs are not "trusted" in the same way that one
trusts a public CA.  Moreover, CAs of this sort are authoritative for
revocation, just as they are authoritative for cert issuance. Tony
seems to agree with this observation, but Bob feels that this is a
naive model re NR.  I will remind Bob that NR is not the only focus
of PKI, that this WG has expended way to much time arguing about NR
matters that seem to never be fully resolved in the technical domain,
and that the lack of uniform agreement re NR requirements suggests
that no single view of technical support for NR can be considered
authoritative.

What you tow are suggesting is a local means of asserting
per-certificate validity judgements that might override those of the
CA who issued a cert. While I can appreciate the motivations that you
cite for this, they are simply not consistent with the overall X.509
or PKIX models. We cannot tailor the specs to compensate for
questionable PKI implementation designs in apps such as browsers.

OCSP does allow for local configuration of a local source for
revocation information, and that would allow one to achieve the goals
you cite, if one relied on OCSP for revocation status.  DPV will
allow a similar configuration capability. So, I suggest that you be
content with the ability to achieve the stated effects via these
other protocols, which will provide the capability as a side effect
of their other design goals.

Steve