Esko Dijk <[email protected]> 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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
