Re: [Anima-bootstrap] [Anima] Voucher signing method

[Michael Richardson <[e-mail]>]

Panos Kampanakis (pkampana) <[e-mail]> wrote:
    > About a), I don't think putting all the CA certs in the voucher is a
    > good idea. EST should be used instead. I don’t think it is right for
    > someone to expect the voucher to distribute its roots of trust. What if
    > a CA cert gets revoked of expires? EST has the transitional certs that
    > allow for root CA cert update, but I don't think we can expect someone
    > to rerun BRSKI in order to get its new root of trust.

If we are worried that the CA cert will get revoked during the validity
period of the voucher, then that implies that the pledge is going to check
CRLs and/or OCSP.
The voucher can have an expiry date, but that is only meaningful to a pledge
with a clock.  Pledges use nonces to avoid that requirement.

I don't think we say anything about the pledge putting some upper time limit
on issuing nonce->getting-voucher.  Pledges could well have relative time.

It's the job of the MASA to validate all the right CAs and CRLs, etc. and to
pick a voucher expiration time to be short enough that the pledge does not
need to worry about such things.

My opinion is that manufacturers should in many cases, simply directly pin
the public key of the owner, and issue vouchers short (and often) enough so
that there are no issues like you describe.

    > The cert chain in the voucher should only enable the client to
    > establish a trust relationship with the server. So, I think only one
    > root cert for the domain should be carried in the voucher. The rest of
    > the certs in the chain of the server cert should be sent by the server
    > in the TLS negotiation.

That works well in the private CA situation, but not in the WebPKI situation
where the root cert would be "Comodo", and every server they have validated
would be a potential owner.  But it also works poorly in a big enterprises
(a multinational oil company) where there are many potential owners of the
pledge, but a central (hierarchy of-) CA which is going to enroll all the pledges.

    > about size improvements. CMS' ASN.1 is not human friendly, but I would
    > be interested if writing the cert fields in free-form JSON and encoding
    > with CBOR/JWT would really lead to a shorter total size. In other
    > words, I am not sure going beyond JSON vouchers/tokens when talking
    > about new encodings (JWT, CBOR) is something we should tackle.

Remember that the goal isn't to initialize the pledge's trusted certificate
store for all future operations. It's just to get the pledge enrolled into
the domain's CA.  Likely all E[cd]DSA operations.

Once the device is connected to the ACP, if a NOC controller wants to
initialize a more complex set of identities, that can be done.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


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