I've read through the diffs: One that jumped out at me: If the API server is identified by IP address, the iPAddress subjectAltName is used to validate the behavior described above.
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? This seems like it's opening a situation where someone will deploy on RFC1918 addresses and then expect clients to do some exception processing. Particularly in corporate guest networks where they only tested with their devices that already have their private PKI anchors. I can think of a few captive portal product managers that I have interacted with that would simply not understand this. I'd rather we didn't allow for iPAddress SANs, but it's not a sword I'll die on. 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. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
