{did I answer this already?}
Benjamin Kaduk <ka...@mit.edu> wrote:
> You mention in a couple places that EAP server certificate should be
> identifying an rfc822Name DN, and I think I'm confused about what you
> mean. (I suspect I'm seeing "rfc822Name" and jumping to what ACP does,
> which is wrong.) Could you walk through an example of what that would
> look like to help un-confuse me?There is no connection to the ACP situation. I think that the idea is that the ESSID would be set to an FQDN, and the EAP-TLS server certificate would have the same FQDN in the rfc822Name. Given ACME dns-01 type challenge, that would provide evidence that the entity was authoritative for the name. In a LE ACME certificate that was issued via dns-01, I found two policy OIDS: 1.3.6.1.4.1.44947.1.1.1 (unknown) and 2.23.140.1.2.1 (domain-validated). I think that domain-validated can mean http-01 or dns-01, but I don't know. I don't know if the above mechanism really works. I don't think that this would matter if the goal was TEAP-BRSKI, because we can pin an EE certificate from any origin. Once the voucher is issued, then the pledge will download a new set of trust anchors, so it doesn't really matter once the device is enrolled. It can then use the new trust anchor with (any) other EAP mechanisms to connect afterwards. Critically, if the trust anchor is a public anchor, then the client needs to pin the rfc822Name as well as the anchor, otherwise any EE issued by the public trust anchor could be a valid authenticator. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
