Esko Dijk <esko.d...@iotconsultancy.nl> wrote:
> Now the target recipient of the PVR is the MASA. (Again for PRM this
> may be different and include Registrar as well...? But not in BRSKI I
> think.) So the requirement on the Pledge is it SHOULD include in the
> PVR all the certificates needed for the MASA to build the complete
> chain.
Since the manufacturer created the IDevID for the pledge, I would think it
(the MASA) has all the required subordinate certificates.
The *Registrar*, however, might not have them all.
It's a tussle.
> The MASA is this solution needs to store all the cert-chains for all
> the Pledges it supports – including their IDevID EE certificates -- an
> extra burden on MASA, compared with BRSKI, but one which helps us
> achieve the smaller size of PVR. So cBRSKI changes the “SHOULD”
> requirement from 8995 to a SHOULD NOT in Section 9.2.2.
I don't think it's a burden :-)
> A registrar accepts or declines a request to join the domain, based
> on the authenticated identity presented
> It doesn’t say where the IDevID identity should come from – PVR or the
> (D)TLS handshake supplied certificates. Having only one source should
> be fine ... ?
Yes.
I prefer getting it from the PVR.
That's much easier in a PRM situation.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
