Subject: Re: [lamps] Using public CA infrastructure for autonomic bootstrapping over EAP.

From: Michael Richardson <[email-masked]>
Date: Sat, 01 Feb 2020 22:46:04 +0100

{did I answer this already?}

Benjamin Kaduk <[email-masked]> 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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [