snip
> Yes, we could put in a bunch of changes in OCSP to make it
> work, but you would end up changing the semantics of a large
> part of OCSP.
>
its best to add a few features to a trusted transport that
serves a common operational function (cert status and validation) than
reinvent the whole box and dice again - re key management, protocol hddr
formats, routing references, etc, etc - and also introduce compatibility
and interoperability when both technologies are used in the same
operational system.
Yes, that's probably true. SCVP doesn't do any of that. This seems like a
red herring. One only has to think of the customer and what they want...
simpler systems, less code changes, less protocols, less databases and
less configuration and more capability and trust - to see what the
logical answer is..
Yes, that's probably true. Do you think that adding the SCVP functionality
to OCSP would not involve more complicated systems and more code changes?
Of course, it is one more protocol, but if you're talking bits on the wire,
the SVCP request and response are carried on the same protocols as OCSP. I
don't know what you mean by more databases or more configuration. If you
want to get the functionality of SCVP in OCSP, you'll need to have the same
databases and configuration, and the same capability and trust.