Re: OCSP Considerations

[Bob Jueneman <BJUENEMAN@xxxxxxxxxx>]

Mike, I either agree with or have no strong opinion regarding most of your
comments, but a couple made me want to stop and think a bit more:

>>3. Both the request and the response need to be signed, at least
optionally,
>>and particularly if there is billing or other information associated.
>
>I agree, particularly with the optional part.
>
>Now, there is a converse side to this capability--unsigned responses.  Some
>may wish to take advantage of this design effect for enterprise-level
>needs.  Within an enterprise, trust is often implicit and security policy
>enforced procedurally.


I am a more than a little bit wary of handing potentially naive users and/or
system administrators this much rope, because of the possibility of a
spoofing attack. Even in those applications where nonrepudiation really
isn't an issue, providing an unsigned "yes it's valid" response to an
inquiry about a certificate essentially wipes out the entire PKI
infrastructure.  I would therefore be strongly opposed to providing unsigned
responses, unless a very convincing case can be made for it, and unless some
other mechanism (validated SSL connection) could be guaranteed.

>>5.  I don't see any particular utility in making the nonce field optional
in
>>the request -- if someone is really convinced that they don't need it,
they
>>can just fill in zeroes, without adding the additional complexity of
>>deciding whether or not it was included, and therefore whether it should
be
>>included in the response.
>
>But doing so then creates complexity and potential breakage at the backend.
>
>I presume this practice is intended to enable pre-production and caching.
>However, this then requires CAs or other trust providers to reliably
>predict the default value in the event they wish to pre-produce signed
>responses.  We could easily agree on an industry-standard default value but
>this alternative also invites the possibility that a given developer will
>get it wrong, deploy their product, and break.  This kind of thing happens
>more frequently than perhaps we all care to admit.
>
>Also, there would need to be at least some minor amount of code written on
>the client to examine the default setting and branch appropriately.  So I'd
>prefer to have this branch to a default of "no inclusion" vs. "default
>value" because it seems to me the client-end complexity is roughly
>equivalent while also providing some benefit at the  backend.

I wasn't trying to enable preproduction and/or caching of results -- far
from it.  In fact, preproduction would be right up there with unsigned
responses as something that I would have extremely strong reservations
about.  My experience is that it is extremely difficult to try to think
though all of the possible ways that someone could try to defeat the system,
and then to decide whether or not those possibilities have been handled
adequately.  Instead, I tend to reach for a bigger hammer, using solutions
that have been tried and proven repeatedly.  Using a nonce to prevent a
reply attack is one of those principles, and if that defeats the use of
preproduced results, then you might as well use an unsigned result, since
you won't known anything with any degree of certainty in any case in that
event. So let's forget about making nonce's optional -- it's too risky.
>
>>
>>7.  It would be nice, but perhaps not essential, to have something in the
>>request that specifically identifies the nonce as consisting of a message
>>digest (SHA-1 by default) of the date/time of the request concatenated
with
>>the digital signature which is being validated by this OCSP request.
>
>I can see where this might be useful for certain applications.  But I would
>not want to assert any requirement that the trust provider confirm this
>construction.  From the trust provider's point of view, the underlying
>structure of the nonce, when included, should be opaque.  Now, this does
>lead us predictably into who is attesting to what in this interaction.  If
>the CA behaves "opaquely", then it is just a status service and subjecting
>itself to one set of potential damages.  If the CA confirms the
>construction, did it just unwittingly become a digital notary?

Hmm.

Perhaps that depends on why you mean by a digital notary.

Let's try a gedanken experiment.  I have in my hand a particular transaction
(which I won't identify to you), and as part of trying to decide whether or
not to trust that transaction, I ask you the CA whether the signer's
certificate is valid.  You say either yes or no, and if you say yes and you
are wrong, I sue you for any ensuing damages, up to the limit of your CPS at
least, and probably for much more if I get a good attorney and prove
negligence.  Since I didn't identity the transaction, or tell you what the
consequences might be, you have no way to know what transaction really went
bad, or how much the damages might be. In fact, you don't even know that
there was any such signed transaction, or what the value might have been, or
when it occurred.

Now we do the same thing, but this time I identify the particular
transaction by its message digest. I still didn't tell you the estimated
value of the transaction or promise to pay you an insurance fee (because you
aren't ready to support that function yet), but at least I confirmed that
there was a particular transaction that I had in mind.  So I can't lay a
trap for you, trying over and over to catch you in an error where you
confirm a certificate as valid which shouldn't have been, and then sandbag
you by making up a transaction to fit some real world events after the fact.

How is the CA any better off in the first case than in the second?  I would
argue the converse, that even without knowing the specifics of the
transaction, the CA is better covered if the relying party who is claiming
damages has to produce a signed response that includes a nonce that matches
a particular transaction, rather than applying to any and all possible
transactions.

Even in the case where the CA or other TTP is provided the estimated value
of the transaction, and the relying party pays a percentage fee to have that
particular transaction covered, the TTP is not acting as a digital notary in
any legal sense of the term.  Instead, they are acting as an insurance
company, probing a simple errors and omission policy for a given amount of
coverage for a predetermined rate.

What they are NOT doing, that a cyber-notary or civil law notaire might do,
is provide assurances that the person whose certificate was being validated
had sufficient credit-worthiness to be good for the value of the
transaction, or that the transaction itself was well-formed and truly
represented a meeting of minds, that the relying party was in fact dealing
in good faith, etc.

So in summary, I don't see any particularly useful distinction between an
OCSP provider who merely returns certificate status, vs. one that provides
the certificate status with respect to a particular transaction, assuming
that the value or other details of the transaction aren't described.  If
anything, the inclusion of a particular transaction nonce would seem to
provide some additional protection against someone trying to sandbag the CA.

Is there some other set of liabilities or functions that you are thinking
about when you use the term "digital notary"? 

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com

"If you are trying to get to the moon, climbing a tree, 
although a step in the right direction, will not prove 
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."