[Emu] using public CAs for IDevID and device certificates

[Michael Richardson <[e-mail]>]

Michael Richardson <[e-mail]> wrote:
    > 3.  End User Client Certificates

    > A client certificate used to authenticate an end user may be used for
    > mutual authentication in TLS, ***EAP-TLS***, or messaging.  The client

    > (to be very very very clear: not a consensus document at this point!!!!)
    > [See followup message, I don't want to distract this thread too much]

It would also be very nice to be use LetsEncrypt for device certificates,
and draft-moriarty-acme-client speaks to some of this, but given 90-day
LetsEncrypt expiry, that won't fly. (I have running code that deals
with the factory processing)

Having an IDevID on a thing (router, appliance, home router) with a public CA
trust path means that one connect to it from a stock browser/smartphone
without error.
Yes, that implies the thing has a name (the name is in the certificate), and
that the name is resolvable by the browser, at least locally.
That's possible, particularly given IPv6 ULA AAAA RR for home routers,
but also using local DNS mechanisms. (again, I have running code)

It is, sadly, not feasible to buy certificates from a public CA, as the
current CAFORUM 2yr (25 month) limit won't work for most supply chain
logistics.  The CAFORUM has been discussing 13 month limits, with noises
for even shorter terms.  I read the lists for awhile, but I don't know if
13 months went to a vote yet.

Okay, I thought: no problem, just get an Enterprise sub-CA with a
nameconstraint limiting issued certificates. That was a thing at one
point.   Surely, I can then control the expiry dates myself?
There was even a CVE about windows-server not validating the name constrained
correctly a decade ago.

I did persue this anyway about a year ago with a few CAs. Only one of them
actually could spell "Enterprise CA"!! It's just not offered, as a result,
I think of the newer CAFORUM rules.  I am sad, but I understand why it
happened.

yes, Enterprise CAs were in order O($10K-USD),
but spread over 100K+ product instances, that's not a huge cost.

I was offered a hosted sub-CA. If I wanted it to have a public trust
anchor, the price was $450/certificate. (Yes, I got the decimal place
right. I did ask for confirmation here twice. I was expecting $4.50/certificate,
with some minimal commitment, given that it would have a PathNameConstraint).
That's for a 25 month certificate, which I thought, maybe is long enough for
the step after proof-of-concept.

With BRSKI ANIMA/ACP, selling into Operators and Enterprises, using a
private CA for the IDevID is just barely acceptable, as those operators
can just probably configure new trust anchors into the Registrar.  Maybe.
With good enough software.  Maybe we can come up with some additional
mechanism, maybe involving SRV and/or TLSA records.

This probably won't fly into the residential or SOHO space, thus the interest
in either having a public trust anchor for IDevID signing, or... CREATING A
NEW SET OF semi-public CAs.    Honestly, this project would be simple
compared to what I've seen of the US Federal cross-CA system :-)

I wrote two documents in December which I'd appreciate feedback on:
1) Operational Considerations for Manufacturer Authorized Signing Authority
   draft-richardson-anima-masa-considerations-01

   This is about the private CA used to sign the IDevID.

2) Operational Considerations for BRSKI Registrar
   draft-richardson-anima-registrar-considerations-01
   This is about the private CA that the operator is expected to run.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-