> 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.
That's right, a public PKI seems the best option for MASA. Other options are
listed in RFC 8995 5.4.1, which allows non-PKI / private certificate chains
also.
Because this may not be a source for getting the chain of the Pledge, I
mentioned that in cBRSKI the Registrar gets it from the Pledge's DTLS handshake.
For a non-promiscuous Registrar: the topmost CA certificate of what the Pledge
sends has to be somehow pre-installed as a Trust Anchor at the Registrar.
I.e. that Registrar type would only accept Pledges from vendors it knows about
beforehand. And it would not resolve the MASA URI further, if it's an unknown
Pledge.
So, in that case having the MASA provide a "/crts" resource for Registrar would
not make any difference, because the Registrar wouldn't connect to the MASA
anyhow.
> I really think we need a new BRSKI-MASA exchange to get the right chain.
Not sure - for cBRSKI this seems not needed, unless we need to make the
handshake smaller, which is not proposed right now.
And for PRM with JWS-voucher, the entire chain will be in the PVR's
envelope/container so the Registrar will get it. There's opportunity to make
the PVR data smaller, but that's also not proposed so far.
> 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.
Or maybe you are proposing to make this size optimization here and write a
document :)
Not yet sure if that's worth the effort.
Esko
-----Original Message-----
From: Michael Richardson <mcr+i...@sandelman.ca>
Sent: maandag 20 januari 2025 19:52
To: Esko Dijk <esko.d...@iotconsultancy.nl>
Cc: anima@ietf.org
Subject: [Anima] Re: Discussion on BRSKI/cBRSKI/BRSKI-PRM requirements on
signing the PVR
Esko Dijk <esko.d...@iotconsultancy.nl> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
