Hello.
Oscar Manso wrote:
Dear all,
Our suggestion to introduce information in the form of OCSP
Extensions was
raised because we understand that through the use of such mechanism
the
Validation Authority could provide dynamic information that could be
useful
in order to take validation decisions. We were thinking of an optional
mechanism served on demand provided through OCSP.
On his last email, Mike mentions other protocols that probably will
be more
adequate to convey such type of information. At this time we are
working on
a GT4 pilot that uses OCSP Extensions as proposed and we expect to
present
you some results soon. On the mean time, we understand that there is
no need
to discuss further the introduction of OCSP extensions in this
document in
order not to delay its publication.
Great! We might get back to the topic later if needed.
However, given the fact that the subject has been raised and that
Mila has
already made some useful comments we would like to comment on them.
Milan Sova wrote:
[...]
Sorry, I don't see the connection to trust chaining (perhaps we
differ in understanding the term). Could you explain your view,
please?
We're interpreting "Trust Chaining" not in the sense of providing
transitive trust relationships between two EECs through mechanisms
like cross-certification, but instead -as mentioned on the note in
page 10 just before section 7.1 of the working document- by creating
a one-way trust relation between a relying party and a CA (Relying
Party -> OCSP Responder -> CA) by signing the OCSP Response with a
private key which correspondent Public Key Certificate has been
issued by such hierarchy. The only condition is that this keypair
must be the same for every configured CA on the OCSP Responder (same
certificate request for every OCSP Signing Certificate being
requested). In practice it means that no additional overhead is
produced with this solution as OCSP Response signatures are created
with the same private key.
Maybe it's not "Trust Chaining" in the broad sense of the word as the
Trust Relation is one-way only , but we hope that the idea is clearer
now... Anyway let us know any question :)
I see. However, from the relying party's point of view there's no
change in trust - it gets the responder location from the cert and
gets the responses signed by the key certified by the CA => the
relying party sees the OCSP service as if it is run by the CA. On the
other hand, it's the CA which must trust the OCSP service provider...
Signing the responder's key by several CAs brings up another issue:
there's the "chicken-and-egg" problem with validating the responder
certificate. Common solution is to set ocsp-nocheck extension in the
responder's certificate and set its validity to a short time. Have you
considered a mechanism for a regular re-certifying the responder?
Regards
--
Milan Sova
sova@cesnet.cz