Martin Thomson <m...@lowentropy.net> wrote:
>> 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.
Again, some enterprise PHB will point to this paragraph and tell the techie
that s/he doesn't need to do things the right way. I've been there.
So I would like to know why we added it. We can specify a subset of RFC6125.
>> 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).
Ah, okay. The CRL is "built-in", so it does not need to be fetched while in
captivity. Thank you.
--
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
