Michael Myers wrote: > > From: Dave Engberg > > > > I would suggest modifying the IKEv2 proposal to permit requests with: > > > > a) More than one responder > > The I-D currently reads "Where it is useful to identify more than one > trusted OCSP responder, each such identification SHALL be transmitted > via separate OCSP Responder Hash CERTREQ payloads." Is this sufficient? Ah, right ... missed that. Thanks. > > b) Specify responders by name or key hash instead of cert hash > > My intent is to keep this as close as possible to the way IKEv2 does > things, especially given our SAAG discussion in San Diego re: PKI > complexity. Hence the Responder Hash "SHALL be computed and produced in > a manner identical to that of trust anchor hashes as documented in > Section 3.7 of [IKEv2]". I do not recall anybody having any problem > with that means of identifying CA certificates. So why not OCSP > Responder certificates? A trust anchor certificate (e.g. a self-signed root) should be extremely long-lived, so a hash of the entire certificate will be a relatively safe way to refer to that anchor. Even if the root CA does need to generate a new certificate, proper key rollover procedures may permit chaining back to the old root. This would allow clients to continue operating without requiring an immediate local change at every laptop. The lifecycle for a responder certificate could be much more dynamic. For example, the most maintainable OCSP infrastructures (IMHO) use pkix-ocsp-nocheck along with shorter-lived responder certs to avoid the problem of determining responder revocation. Responder certs don't have any way to do "rollover" to a new cert with implicit trust for existing clients. This means that any change to the responder cert requires a local change on every peer device. > > c) Permit "delegated" responders (OCSPSigning) without > > explicit trust at the relying party > > Such is not excluded by the I-D. We make no assertions about what is at > the other end of that Responder Hash. If an environment wants that > certificate to contain the indicator for explicit delegation of OCSP > signing, it is free to do so. Or did I miss your point? Sorry, I meant that it would be useful to allow the "service" side to send an OCSPResponse along with a delegated/chained responder cert that isn't explicitly known to the "client" before the transaction starts. This would allow the client to say, "You may send me a response signed by any proper delegated responder cert." The client receives the responder cert with the response, and confirms the chaining delegation to the CA. This permits the greatest flexibility in the responder management without introducing another hard-coded trust point in every client.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec