Esko Dijk <[email protected]> wrote: > We've discussed this exact idea in 2022/2023 - it is captured in the > issue https://github.com/anima-wg/constrained-voucher/issues/239 .
Thank you for reminding us of the discussion.
I'm not sure that the Registrar can get a full chain my doing just TLS with
the MASA. The MASA's https port *ought* to have a public WebPKI anchor, not
a private one.
I really think we need a new BRSKI-MASA exchange to get the right chain.
> This was marked as future update for cBRSKI, because it would require
> extending the base BRSKI protocol and its resources.
That's true *only* for the promiscuous Registrar.
We could save those bytes and make a standards track document on promiscuous
registrar operations, which would include some way to get the subordinate
certificates needed.
I'm okay with going forward with this advice now.
> The extreme reduction case I mention does have a slight
> security/privacy disadvantage: the Registrar can't evaluate the cert
> chain as a whole prior to deciding whether to contact the MASA URI, or
> not.
Yes, I agree that this is a risk.
There might be multiple ways to get that chain though: DNS CERT records, DNS
TLSA records, and maybe other to-be-defined industry trust anchor stores.
> I.e. the MASA/vendor can potentially harvest more sensitive data about
> what its customers are trying to do.
> There's also less extreme scenarios possible of course e.g. where only
> the root CA is elided in the handshake.
Up to you.
>> That would keep the size of the subordinate certificates out of the
>> BRSKI-EST.
> Just to note on this: In cBRSKI, this size is only included once in the
> handshake traffic. Certificates are not present in the signed PVR -
> only a signature is there.
Good point.
--
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]
