David Wierbowski writes: > >>I agree with the wording Tero has provided and I think that is > >>what the intent of the original text was. > > > >We disagree here. The point of hash-and-URL was to prevent people from > >sending certs.
There are two things here, there is HTTP_CERT_LOOKUP_SUPPORTED and Hash-and-URL formats. The HTTP_CERT_LOOKUP_SUPPORTED means: This notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL (and hence presumably would prefer to receive certificate specifications in that format). Here this "prefer to receive certificate specifications in that format" is meaning the Hash-and-URL formats. > We do not disagree. The point of hash-and-URL is to prevent people from > sending certs and it does. The certificate is not sent when when a > hash-and-URL is used. A hash and URL of the certificate is sent. That hash > and URL is sent in a certificate payload. Note you did not say that the > point of hash-and-URL is to prevent people from sending certificate > payloads. I think Tero's current wording does prevent the cert from being > sent. Yes. I.e. if you see HTTP_CERT_LOOKUP_SUPPORTED, you still send Certificate payloads, but they do not contain full X.509 certificates, they contain Hash-and-URL of the certificate. The idea was that you include CERTREQ for X.509 Certificate - Signature (4) format containing the trust anchor information. Then you can also include HTTP_CERT_LOOKUP_SUPPORTED notification in the same packet to indicate that in addition to that format (4), the other end can also use Hash-and-URL formats as you support fetching the certificates using HTTP. Now the other end has two options. If it can provide url for the certificate (i.e. it for example runs its own http server which contains the certificate, and it can send hash of the certificate and make url pointing to that server running and make sure certificate is available from there), it would be better to use that Hash-and-URL format. On the other hand if it is behind NAT, and knows that it cannot start http-server in such way that other end can reach it, then there is no point of using hash-and-URL format as the url would not work, so it can use normal X.509 Certificate - Signature (4) format instead. Of course the the url could also point to the CA server or some other server, but the version I described above was one of the intended ways also (we had discussions on the ipsec list what do to if the http connection between ipsec peers is not possible, and one solution was to store the certificate to some other server). -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec