Subject: Re: SCVP Analysis

From: "David P. Kemp" <[email-masked]>
Date: Thu, 15 Jul 1999 11:15:34 -0400 (EDT)

> From: Michael Myers <[email-masked]>
>
>   [...]
>
> We have three system level-functions being addressed by this protocol:
> 
> 1.  Fully delegated path validation;
> 2.  Lightweight PKI data access; and
> 3.  Remote certificate parsing.
> 
> The need for the first capability has been fairly obvious for years.  The
> latter two are of questionable value, with perhaps the exception of
> returning back the intermediate chain.
>
>   [...]
>   
> 7.  Optional specification of trusted roots the server must rely on.
> ----------------------------------------------------------------
> Same issue as above.
> 
> Is it the authors' proposition that the issuer of a certificate is *not* the
> final arbiter of the trustworthiness of that certificate?  (noting that
> "issuer" could be an entity that directs another entity to manufacture and
> distribute a certificate on its behalf).

Very nice taxonomy.  I agree that function 1 is needed and that function 3
is of questionable (IMO, zero) value.

I believe that the model described by Ms. Bitan, function 2 where the
server is an untrusted certificate fetching, caching, and chain
building engine, is useful.  In that model, it is useful for the client
to optionally pass it's trusted cert(s) to the path building server,
since the server might not know which certs are trusted by a particular
client at a particular time for a particular purpose.

The distinction between models 1 (where the client trusts the server to
do its security processing) and 2 (where the only security requirement on
the server is to be available) should be made explicit.  The distinction
would be clearer if different messages were used, rather than populating
different optional fields in a single message.

> 9.  Extensions may be critical or non-critical.
> ----------------------------------------------------------------
> Recent experience has shown that this is inadvisable.  The XML DigSig group,
> for example, has specifically deprecated proposed use of critical flags for
> well-known reasons.

I agree that critical flags should not be used.  When defining a new
protocol, there is no need to support half- ummm, baked interoperability
with an installed base of non-compliant implementations.  And when a
"critical" flag is overloaded to modify the semantics of an extension,
the clarity of the specification is further diminished.

The static flags MUST, SHOULD, and MAY in the protocol specification
are sufficient indicators of criticality.

---

From: "Ambarish Malpani" <[email-masked]>
Date: Thu, 15 Jul 1999 11:29:38 -0700

> 
> Hi Mike,
>     Thanks again, for looking at this so carefully.
> 
> More comments inline:
> 
> Regards.
> Ambarish
> 
>  
> > > 
> > > > All,
> > > >
> > > > The SCVP draft raises some interesting questions
> > > which deserve discussion
> > > on
> > > > the list.  Below are some thoughts to get that
> > > started.  Having gone
> > > through
> > > > this process, it's very clear to me at least that
> > > needs for delegated path
> > > > validation can more easily be met with a very
> > > simple extension to OCSP.
> > > The
> > > > work would be very minimal compared to
> > > implementing a totally different
> > > > protocol to do exactly the same thing.
> 
> Mike, I think we disagree about this topic. OCSP
> was designed to do cert status checking and it does that
> very well. It was never meant to take over the job
> of cert chain building or make trust decisions for the
> client.
> 
> Yes, you could merge the syntaxes of OCSP and SCVP, but
> I am not sure that would be a good approach. I actually
> see the OCSP server responding for the CA, while the
> SCVP responder, would normally sit in an organization
> and implement the security policy of the organization.
> 
> 
> > > >
> > > > Mike
> > > >
> > > > REQUEST SYNTAX AND SEMANTICS
> > > >
> > > > 1.  Optional use of a RequestHash  in lieu of a
> > > digitally signed request.
> > > >
> > >
> > 
> ----------------------------------------------------------------------
> > > > The need to integrity-protect the request hasn't
> > > been established.  How is
> > > > this request-response protocol different from,
> > > say, LDAP?
> > > >
> > > > It seems that requestHash is actually presumed to
> > > be sufficient for the
> > > > non-repudiation needs of accountability in some
> > > environments.  If so, this
> > > > needs to be made explicit and-more
> > > importantly-discussed on the list as
> > > such
> > > > a resolution impacts assumptions underlying
> > > current trade in certificate
> > > > validation services.
> > > >
> > > > If however the authors assert that the requestHash
> > > field is unreliable for
> > > > service accountability and is meant rather simply
> > > as an integrity check,
> > > the
> > > > requirement for integrity protection equally
> > > merits discussion of the
> > > > security risks being addressed.  Perhaps the
> > > authors have some insight
> > > into
> > > > security risks that were overlooked in prior PKIX
> > > protocols now standing
> > > as
> > > > RFCs.
> > > >
> > > > Should that discussion conclude that the request
> > > syntaxes of PKIX
> > > protocols
> > > > need to be integrity protected, it seems we may
> > > need to amend the
> > > > request-response protocols PKIX has currently sent
> > > up to IESG which do not
> > > > provide such protection.
> > > >
> > > > Should that discussion otherwise conclude that
> > > certificate validation
> > > > protocols are unique among other protocols in
> > > their need for integrity
> > > > protected requests, at a minimum this may affect
> > > RFC 2560 (OCSP), which
> > > > bears a striking architectural similarity to the
> > > proposed protocol.
> > > >
> > > > In the absence of resolution of either of these
> > > positions, the
> > > functionality
> > > > seems superfluous.
> 
> No, the requstHash is not superfluous or arbitrary. And
> no, you don't need to add it to an OCSP request.
> 
> The purpose of the requestHash is to prevent a man
> in the middle from changing the request (if it is an
> unsigned request). The reason this is important for
> SCVP (and wasn't so for OCSP), is that we allow a client
> to specify the trusted roots and the usage he
> wants to trust a cert for. Also, if a client doesn't need
> the chain the responder built, it is very likely that it
> will *not* ask the responder to return this chain, or check
> it if it is returned. In this case, if a person could get
> in between the client and the server, he could arbitrarily
> change the request to get the client to server any set of
> roots - not something we would like to encourage :-)
> 
> In OCSP, the client is expected to make sure that the
> response corresponds to the request, by making sure that the
> CertID in the response matches that of the request.
> 
> Hope this clarifies things.
> 
> > > >
> > > > 2.  Explicit specification of a request being a
> > > path validation request
> > > vs.
> > > > a revocation status check.
> > > >
> > >
> > 
> ----------------------------------------------------------------------
> > > > The proposed BIT STRING construct fails to
> > > adequately accommodate future
> > > > evolution of the semantics of certificate
> > > validation.
> > > >
> > > > In a more general framework, one could specify
> > > request types using
> > > OID-based
> > > > extensions as we do today with X.509, and as
> > > currently established by RFC
> > > > 2560 (OCSP).
> 
> Paul and I had already talked about making this change. We agree
> with you. I believe we will make both the WantBack and the
> TypesOfChecks a sequence of OIDs.
> 
> > > >
> > > > 3.  Optional inclusion of the subject certificate
> > > in the request.
> > > >
> > > > This seems to be a reasonable requirement.
> I don't think this is optional. The client *must* include the
> subject certificate. I think the text specifically states that.
> 
> Paul, I think we should make the text more obvious - I missed that
> the first time also.
> 
> > > >
> > > > 4.  Optional support for PGP style public key
> > > management.
> > > >
> > > > As discussed on the floor in Oslo, inclusion of
> > > this functionality would
> > > > require a revision to the PKIX charter.  PKIX was
> > > specifically established
> > > > to address X.509 certificates.
> > > >
> > > > 5.  Optional request for the value of subject
> > > public key, subject name,
> > > > certificate chain or revocation proof.
> > > >
> > > > If it is the objective of the proposed protocol to
> > > fully delegate path
> > > > validation to an external server, then this
> > > functionality isn't in line
> > > with
> > > > that model.  This looks more like a lightweight
> > > data access protocol.
> > > >
> > > > Further, requests for the public key and subject
> > > name seems odd against
> > > the
> > > > prior capability to include the certificate in the
> > > request, which
> > > obviously
> > > > assumes the requester has the certificate.
> > > >
> > > > So in this instance the server is acting like a
> > > remote certificate parser.
> > > > If that's indeed the authors' intent, then the
> > > proposed functionality is
> > > > incomplete.  For completeness, they should
> > > consider remotely parsed access
> > > > to:  subject alt name extension for IPSEC;
> > > certificate policy values for
> > > the
> > > > policy engines; subject directory attributes for
> > > environments using that
> > > > extension.
> > > >
> >From some of the comments at the meeting, it is not quite
> clear to me that the first capability is fairly
> obvious to everyone even today!
> 
> Anyway, the driving force for this spec was to allow the
> client to be as small as possible and to delegate as
> much of the processing as possible to the server. Our
> original thought was that we might be able to allow the
> client to not even need ASN.1 parsing capability. Given where
> the WG is today, we are withdrawing that thought. We do
> need the client to be able to deal with ASN.1 (the tiny
> syntax is going to be removed for now). This makes the need
> for the public key and subject name less important. However,
> the requirement to allow the client to ask for the cert chain
> and revocation proofs back is still important. Clients may
> choose to use the SCVP server as essentially a data gathering
> element that can collect the relevant data (using LDAP, OCSP
> or whatever) and give it back enough information to prove
> to itself that the cert is good.
> 
> > > >
> > > > 6.  Optional specification of intermediate
> > > certificates to use as a
> > > > supplement to the validation path of the subject
> > > certificate.
> > > >
> > > > In the context of the legal framework underpinning
> > > the use of certificates
> > > > for electronic commerce, the issuer of a
> > > certificate issued that
> > > certificate
> > > > with a very specific trust chain model in mind.
> > > >
> > > > The proposed functionality seems to suggest that
> > > the authors are asking
> > > PKIX
> > > > to support the notion of the "re-purposing" of
> > > certificates for uses
> > > beyond
> > > > those intended by the original issuer.
> > > >
> > > > Was this the authors' intent?  If not, then what
> > > problem is this proposed
> > > > functionality solving?
> 
> Nothing so deep or fundamental. It is quite possible that
> the client has obtained some intermediate certs as part
> of its communication with the cert holder (e.g. you can
> get a cert chain in SSL). These certs might not be easily
> accessible to the SCVP responder, since it might not know
> where to go for these intermediate certs. The purpose of
> passing these certs to the responder is to make its chain
> building task easier. There was no intent to subvert the
> issuer's intent.
> 
> > > >
> > > > Is it the authors' proposition that the issuer of
> > > a certificate is *not*
> > > the
> Again Mike, nothing very deep and fundamental here. It is
> quite possible that the SCVP client has a set of roots/certs it
> trusts. It might want all chains built to that/those roots,
> rather than to any roots the responder might choose to trust.
> 
> 
> > > >
> > > > 8.  Optional configuration identifier that points
> > > to a pre-defined set of
> > > > the above options.
> > > >
> > > > This seems to be a reasonable requirement.
> > > >
> > > > Recent experience has shown that this is
> > > inadvisable.  The XML DigSig
> > > group,
> > > > for example, has specifically deprecated proposed
> > > use of critical flags
> > > for
> > > > well-known reasons.
> 
> I am not sure I agree with this conclusion. It is quite possible 
> that an entity wants to make a query that contains some important
> semantics. It only wants an answer if the responder understands
> those semantics. Critical extensions do make sense when people try
> to use this base protocol in different environments.
> 
> > > >
> > > > RESPONSE SYNTAX AND SEMANTICS
> > > >
> > > > 10.  "Unrecognized" error codes related to the
> > > above optional request
> > > > protocol elements.
> > > >
> > > > No issues, other than alignment with the prior
> > > analysis.
> > > >
> > > > 11.  Validation response values for "valid",
> > > "notValid",
> > > > "temporarilyUnknown" and "unknown".
> > > >
> > > > This seems to be a reasonable requirement.
> > > >
> > > > Except perhaps for "temporarilyUnknown".  What
> > > does a client do with that?
> 
> "temporarily unknown" is a way for a server to say
> that it does normally know about that particular cert, but can't
> provide an answer right now - for example if it can build the
> chain, but not obtain revocation proof. The client can infer
> that it can go back to the server at a later time with similar
> certs.
> 
> 
> > > >
> > > > 12.  Optional inclusion of an errorMessage text
> > > string
> > > >
> > > > This seems to be a reasonable requirement.
> > > >
> > > > 13.  Optional inclusion of subject public key
> > > value, subject name or path
> > > > validation chain, consistent with prior request.
> > > >
> > > > See point #5 above.
> See response to point #5 above
> 
> > > >
> > > > 14.  Optional inclusion of requestHash appearing
> > > in request.
> > > >
> > > > See point #1 above.
> See response to point #1 above.
> 
> > > >
> > > > 15.  Optional inclusion of revocation proof
> > > content.
> > > >
> > > > See point #5 above.
> See response to point #5 above
> 
> > > >
> > > > 16.  Optional use of a digital signature
> > > >
> > > > This is the same as OCSP: some error conditions
> > > don't need to be signed.
> > > > However, the proposed protocol goes on to assert
> > > that other types of
> > > > responses don't need to be signed if conveyed over
> > > a secure channel.
> > > >
> > > > An optional signature on an affirmative response
> > > is equivalent to an
> > > > unsigned CRL.  It can't be used to support
> > > non-repudiation.
> 
> Again, it depends on what the client is using SCVP for.
> If it is using SCVP in an intranet mainly for policy
> management, it might not care whether the response is
> signed or not. If non-repudiation is important, the
> client will need a signed response.
> 
> Hope this clarifies things,
> Regards,
> Ambarish
> 
> P.S.
> Paul,
>     I think we should include some of these clarifications
> in the next revision, so that other readers aren't confused.
> 
> Ambarish
> 
>

---

From: "Waters, Stephen" <[email-masked]>
Date: Fri, 16 Jul 1999 13:38:09 +0100

Too many protocols? Too right! I've lost track of the number of
protocols/formats being proposed to do on-line enrolment and CRL.

It would be quite useful to have CA and related product vendors(e.g. OCSP
servers) agree to implement a common, mandatory approach.  Once we have
that, addition mechanisms can be supported.  

I did some thinking on how I'm going to collect policy for VPNs. COPS seems
on way, and I made a suggestion that the COPS server could also perform the
function of the OCSP server.

Could it be the policy/OCSP/SCVP could all be managed via a single protocol
(COPS)? No, that would be too easy. If I want to look up a policy each time
a user connects to my PKI/VPN, I could pass a certificate to the
COPS-OCSP-SCVP server, have that server validate the certificate, check the
CRLs, lookup the policy and return me the certificate fields of interest (if
my system isn't able to do that for its self), and the policy.

Steve.

-----Original Message-----
From: Antonio Maña [mailto:[email-masked]]
Sent: Friday, July 16, 1999 11:49 AM
To: IETF PKIX list
Subject: Re: SCVP Analysis

Michael Myers escribió:
> 
> All,
> 
> The SCVP draft raises some interesting questions which deserve discussion
on
> the list.  Below are some thoughts to get that started.  Having gone
through
> this process, it's very clear to me at least that needs for delegated path
> validation can more easily be met with a very simple extension to OCSP.
The
> work would be very minimal compared to implementing a totally different

I share your opinion.

> ...
>
> 4.  Optional support for PGP style public key management.
> As discussed on the floor in Oslo, inclusion of this functionality would
> require a revision to the PKIX charter.  PKIX was specifically established

The new version of PGP will support X.509 certificates, so it seems
that this opens the door to the generalised use X.509 certificates.
In this situation I do not believe that including PGP certificates
is worth the effort.
See
http://www.pgpinternational.com/product/pgp60features.html

Cheers,
Antonio Maña.

  +--------------------------------------------------------+
  !           _   ,                                        !
  ! Antonio Mana Gomez               eMail: [email-masked] !
  !              http://www.lcc.uma.es/~amg                !
  +--------------------------------------------------------+
  ! Departamento de Lenguajes y Ciencias de la Computacion !
  !      E.T.S.I.Informatica.        Desp. 1.2.B.19        !
  !                  Campus de Teatinos.                   !
  !                 29071 MALAGA (SPAIN)                   !
  +--------------------------------------------------------+
  ! Phone: (+34) 5 213 27 54        Fax: (+34) 5 213 13 97 !
  +--------------------------------------------------------+
  ! KEY SERVER:                                            !
  !   Cert'eM at http://socrates.crypto.lcc.uma.es         !
  +--------------------------------------------------------+

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 18 Jul 1999 18:12:32 +0200

Ambarish has answered many of your misplaced assumptions and assertions. I 
can fill in on a few.

>Having gone through

Mike, you didn't respond to my previous statement about this, so please do 
so now: how? The semantics in the OCSP standard explicitly talk only about 
status, and not about validation. Yet now you are talking about validation 
through the extension mechanism. This is a violation of the standard. You 
can change the semantics of OCSP to handle topics other than status, if you 
want, but then it is a different protocol.

>protocol to do exactly the same thing.

Your definition of "exactly" differs from many people.

>4.  Optional support for PGP style public key management.

I would have hoped you would have read the charter before making a 
statement like this. In fact, the charter says nothing of the sort; if you 
disagree, please quote the charter.

In fact, the charter does say "This project will not preclude use of 
non-infrastructural public-key distribution techniques nor of non-X.509 
PKIs by such applications." That seems pretty clear. If you want to try to 
revise the charter to remove this, go ahead, but don't claim it doesn't say 
it in the current charter.

>6.  Optional specification of intermediate certificates to use as a
>supplement to the validation path of the subject certificate.
>In the context of the legal framework underpinning the use of certificates
>for electronic commerce, the issuer of a certificate issued that certificate
>The proposed functionality seems to suggest that the authors are asking PKIX
>to support the notion of the "re-purposing" of certificates for uses beyond

It only "seems to suggest" this to you; no one else seems to have read it 
this way.

>Was this the authors' intent?  If not, then what problem is this proposed
>functionality solving?

Maybe we need to make this clearer in the draft. If a client has what it 
thinks is a chain to the root (because the cert holder has said it is a 
chain), the client can ask the simple question "Is this really a valid chain?"

>7.  Optional specification of trusted roots the server must rely on.

Boy, you seem almost masterful at misreading the draft. Of course not. The 
optional specification of trusted roots is the client's way of saying to 
the server "I don't care who you trust, here is who I trust." This is 
precisely what is needed for the folks who trust the server with the 
ability to process but not to know who is a trusted root.

>9.  Extensions may be critical or non-critical.

And here I'll disagree with Ambarish. We put it in to match the PKIX format 
draft. I, for one, am happy to take it out if the other folks in the WG 
think it should be removed.

If you have any further questions on the draft, please feel free to ask. We 
should have a new version out that covers the concerns raised in Oslo in 
about two weeks.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Michael Myers <[email-masked]>
Date: Mon, 19 Jul 1999 07:48:56 -0700

Paul,

>it in the current charter.

Actually, I was just reflecting what I thought heard on the floor.  We'll
have to wait for the minutes to know for sure.

But for a fuller context, the charter also states:

"The task of the working group will be to develop Internet standards needed
to support an X.509-based PKI. The goal of this PKI will be to facilitate
the use of X.509 certificates in multiple applications which make use of the
Internet and to promote interoperability between different implementations
choosing to make use of X.509 certificates."

And, to provide more context to your excerpt:
"Candidate applications to be served by this PKI include, but are not
limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols,
Internet payment protocols, and www protocols. This project will not
preclude use of non-infrastructural public-key distribution techniques nor
of non-X.509 PKIs by such applications.

So this issue might reduce down into answering the question "What does 'not
preclude' mean with respect to "such applications"?  A more restrictive
interpretation might infer that PKIX's existence should not be taken by
other WGs as the only means of dealing with public-key technology.  That is,
OpenPGP is free to do what they want, as is TLS, IPSEC, etc.  Thus PKIX was
chartered to ensure that those applications were well-equipped to use an
X.509-based PKI if they chose to.

I suspect this might have been the intent, but this is clearly an issue for
the chairs to resolve.

>chain), the client can ask the simple question "Is this really a valid
chain?"

So yes, more clarity and precision in the problem statement this
functionality is solving would help.  I read the following:

"The IntermediateCerts item specifies to the server the intermediate
certificates that the server MAY use when forming a certificate chain in
addition to any other certificates that the server knows of."

to somehow enable a client to establish reliability of the certificate under
a chain other than the one it was issued under.   More specifically, the
phrase "in addition to any other certs the server may know of" seemed to
suggest a functionality whereby the server would ignore the subject
certificates' chain which it "may know of" in favor of the one the client
provided.  Which didn't make a lot of sense, but the lack of clarity in the
problem statement led me to speculate if this was the original intent,
details to be clarified later.

What I understand now from your response and Ambarish's is that this
functionality could be used by, say, an S/MIME client which just pulls the
cert blob from SignedData and throws it all at the server.  To the extent
this blob contains a chain, that makes sense.  But if that's the case, then
what's the meaning of the phrase "in addition to any other certificates that
the server knows of?"   Also, this usage scenario strongly suggests a
SEQUENCE of cert to simplify implementation of delegated path validation on
the client side.

>ability to process but not to know who is a trusted root.

I've read through this several times but I'm still having some problems
trying to understand how this is intended to be used within generally
accepted PKI practices.

How precisely does the phrase "I don't care who you trust, here is who I
trust"  relate to the root the subject certificate was originally issued
under?  Especially in the absence of any cross-certification between roots?
Or, is this functionality intended to be used in cross-certification
contexts.  For example, where the recipient of a certificate issued under a
PKI external to that recipient's trust domain wants to confirm that the
subject certificate is trustworthy due to the existence of a cross
certificate between recipient and originator domains?

I think this is really just an extension of the functionality discussed in
point 6, whereby the client is the seat of all trust, the server is just a
remotely "programmable" engine and the client just sends the entire cert
chain from root to subject cert.

Or maybe not.  But it's definitely difficult at this point to try and relate
the proposed functionality to generally accepted PKI practices.

>think it should be removed.

Well, at least we have arrived at one point of agreement!

Mike

---

From: Michael Myers <[email-masked]>
Date: Mon, 19 Jul 1999 07:53:43 -0700

Ambarish,

Responses embedded below, included text abbreviated for clarity.

> of cert chain building or make trust decisions for the

I've already established a response to this position in my response to
Paul's comments.  The semantic definition of the "good" response clearly
reflects an intent for OCSP to address validation mechanisms using
extensions.  That the current RFC reads as it does reflected an intermediate
need to direct immediate attention at solving the revocation problem.   That
is a stop along the way, very much like defining a base certificate
structure first and then moving on to the more sophisticated extension
concepts.

To your second sentence, taking the entire set of trust decisions for
clients seems a bit out scope for PKIX.  I'm willing to be convinced
otherwise, but I wonder if that view is widely shared.  I'm thinking
specifically of IPSEC clients and their rich set of needs for security
policy enforcement.  Somewhere we have to draw the line at what is X.509 PKI
and what more legitimately within the scope of security applications.

> and implement the security policy of the organization.

You may recall that OCSP very early on established the concept of an
Authorized Responder.  This extension of then-accepted trust models enabled
OCSP to be used by trusted entities other than CAs to speak to the
reliability of a certificate.  For example, it enables banks to produce
digitally signed responses regarding the reliability of a certificate for a
given online transaction.  Indeed, this constituency was influential in
shaping the emergence of this architecture.

It's interesting however that you should characterize SCVP more as a
security policy enforcement solution.  I'll have to add that to my taxonomy
of problems the protocol is intending to solve.  That is:

1.  Delegated Path validation;
2.  Lightweight PKI data access;
3.  Remote certificate parsing; and now
4.  Security Policy enforcement

I can't dispute the existence of a need to establish a standard means of
facilitating security policy enforcement.  If this is indeed your objective,
which I assume it is now that you've mentioned it, then perhaps we can
collaborate on the clarifying the requirements implicit in an online
security policy enforcement protocol and in so doing reduce if not eliminate
the confusion that SCVP creates regarding online validation of digital
certificate reliability.

> wants to trust a cert for.

So a note clarifying that the hash SHOULD NOT be taken as an authentication
mechanism for the purposes of service accountability would help to make this
point more clear.  To further enforce this, put the hash in the root
specification syntax.  It's otherwise predictable that the hash will be
taken as a de-facto request authentication mechanism regardless of the
content of the request.

> Also, if a client doesn't need

Could you please try again to explain the above in different words?  It's
difficult to follow your line of reasoning.  I believe what you are claiming
is that use of a SHA-1 hash in and of itself enables detection of
modification of a request by a malicious third party.  Correct?

> response corresponds to the request, by making sure that the
Ø CertID in the response matches that of the request.

That's certainly one way of doing it.  One could also use the nonce
extension in OCSP to match received responses to prior requests.

> Hope this clarifies things.

Not entirely.

> I don't think this is optional. The client *must* include the
Ø subject certificate. I think the text specifically states that.

I inferred the optionality from the following syntax:

FullRequest ::= SEQUENCE {
    . . . 
    certsQuery           CertsQuery,
    . . . 
}

CertsQuery ::= SEQUENCE {
    certBundle        CertBundle,
    . . . 
}

CertBundle ::= SEQUENCE OF CertItem

CertItem ::= CHOICE {
    fullCert      [0] Cert,
    certID        [1] CertID
}

So it appears that one has a choice of cert or certID.

> building task easier. There was no intent to subvert the
Ø issuer's intent.

As I noted in a response to Paul, addition clarity and precision would be
useful here.

> rather than to any roots the responder might choose to trust.

This makes sense in a cross-certified context, but other than that, a client
can't force a subject certificate to somehow validate under an arbitrary
root.  What entity signed the CA certificate needed to validate the
signature on the subject certificate, a process I presume is carried out at
the server?  And what entity signed that CA certificate, such that the
server can competently complete that signature validation?

I think this concept of clients sending in arbitrary roots needs a good deal
more clarity and precision against generally accepted PKI practices.  If you
say it was expected to be used in the context of cross certification, fine.
But that's not what I hear you saying quite yet.

> that it can go back to the server at a later time with similar

In the case you cite, would not it be more accurate to identify that
particular state as "revocationProofUnavailable"?  That at least is a
reasonably unambiguous response for a client to represent in a UI.  In the
face of a response that makes it clear that the response isn't backed by
access to revocation data, the user of the client can make up her own mind
whether or not to trust the subject certificate anyway.

But I'm having a hard time trying to imagine what a client would present in
a UI to a user upon receipt of "temporarilyUnknown".  One thing is certain:
a literal translation of this state into a UI is not going to meet usability
concerns of PKI I hear about daily.  If anything, we need to work
aggressively to reduce this kind of UI noise.

> client will need a signed response.

This specific principle was brought up very early on in the OCSP design.  
The fact is, unsigned responses so easily enable insider attacks against
other insiders that the security assurances claimed by the technology are
embarassingly baseless.  Remember, it's not just non-repudiation, but strong
authentication we also get from digital signatures.

We are responsible for engineering across the Internet.  As soon as one sets
an intranet context, there are numerous ways of addressing these
requirements, including the use of LDAP and its various authentication
schemes, signed attributes, etc.  That problem's been solved.  That dirt's
been dug.  It's the Internet problem we are chartered to deal with.