On Mon, Aug 10, 2020, at 14:18, Michael Richardson wrote: > I've read through the diffs:
Thanks! > This was added based upon some review comment. > While I can't really object to the idea, I am concerned. > What are the transports that result in only being able to provide a public IP > address? How many common PKI trust anchors are supporting iPAddress SANs > today? There are no methods for providing an API URL that don't support a domain name. That said, this iPAddress thing is just reiterating a requirement from RFC 6125. It isn't *widely* supported, but most clients do respect iPAddress SANs (browsers do for certain), and there are a couple of CAs that support issuance. ACME recently grew a validation mechanism for IP (RFC 8738). > I'd rather we didn't allow for iPAddress SANs, but it's not a sword I'll die > on. Ack. Personally, I'm more concerned about implementations allowing an override option other than through modifying the trust store. A domain name is equally problematic there (let's hope we don't see .home addresses...). But I don't see any easy path to a per-host override based on what I've seen in implementations so far. > The next part says: > An Enforcement Device SHOULD allow access to any > services that User Equipment could need to contact to perform > certificate validation, such as OCSP responders, CRLs, and NTP > servers; > > That's a good list, and that list can be seen from looking at the > certificates that the captive portal operator is going to use. > But, aren't there *also* systems (Mozilla? Chrome?) where the respective > vendors are collecting that info into a central place to make stuff go > faster? I can't quite find what I'm looking for in a search, because > OCSP-Stapling is not what I'm talking about, and eliminates the need. Yes, browsers are providing systems that help with revocation. Mozilla has OneCRL and CRLite; Chrome has CRLSets; offhand, I don't know what Microsoft and Apple might be doing differently. Those systems that I'm aware of don't require network access at validation time. The whole point being to provide timely information about revocation without depending on a live OCSP or CRL fetch (which have poor privacy properties in addition to adding to fragility). _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
