Re: [IETF-PKIX] OCSP using SSL/https

[Luis Valente <luis@xxxxxx>]

At 03:14 PM 12/3/97 -0500, you wrote:
>>I'm having trouble figuring out what exactly you mean by your last
>>sentence above.  Are you suggesting that if the sender and receiver are
>>under the same CA then non-repudiation cannot really be achieved?  Any
>>clarification would be helpful...
>
>
>I said 'authority', not 'certificate authority' and used it in the context
>of 'controlled by'. If I own and operate two machines at different locations
>and believe the machines to be equally trustworthy the value of ensuring
>that a communication is non repudiable is pretty questionable. What is the
>value of preventing repudiation by me of messages I am sending to myself?
>
>The question is whether the advantages of allowing this mode of use are
>worth the cost of supporting it. I doubt this is the case but if I turn out
>to be wrong for some reason I would prefer folk to use 'unsignd OCSP' than
>inventing a new protocol whose only real difference was avoiding signing.

Phil,

I have an application that operates under the scenario you described above,
i.e., a set of client machines that fully trust a secure server for the
purpose of online checking of a certificate's status. Thus, if OCSP forces
me to sign every response, I will have to invent the "unsigned OCSP"
protocol, as you surmised.

>
>Proposal:
>
>I suggest that unless there is an immediate need for this mode of operation
>it is left out of the current draft except possibly to note it as an option
>if people feel there is a major demand.

Personally, I support Dan Laska's suggestion of mentioning SSL (or other
external mechanism) as an alternative authentication mechanism for OCSP
(with all the caveats about non-repudiation that will let folks here sleep
at night).

>
>
>            Phill
>
>

/Luis
--------------------------------------------------
Luis F. Valente             Phone: +1 650 631-4654
Network Computer, Inc.      Fax:   +1 650 631-4057
www:  http://www.nc.com     Email: luis@nc.com