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
