Hi Kevin,

what I am inferring here is that keytrans intends to treat key material as opaque blobs, which sounds absolutely fine to me. But :-)

* why would that exclude symmetric keys?
* does the current charter imply that keytrans will use 'IETF-made' verifiability mechanisms based on JOSE or COSE?

It seems to me that every indiviudal party is intended maintain their own personal private append-only log? I am not sure how else you are trying to address PII requirements?

Opaque blobs are capable of expressing symmetric key serialiations,
or other key serializations, for example:

application/jwk+json [RFC7517]
application/jwk-set+json [RFC7517]

application/cose [RFC9052]
application/cose-key [RFC9052]
application/cose-key-set [RFC9052]
application/cose-x509 [RFC9360]

Securing content of known types is well solved for in JOSE and COSE.

Opaque blobs can also be used to be used to store any attribute of an identity document,
for example, date of birth, or government identifiers, such as social security numbers.

In consequence, my assumption is that you intend to proof to other parties that you are maintaining such a personal append-only log? Is that assumption correct? In general, using MLS as the sole source of requirements without taking into account other IETF activities would appear artificailly constrained to me.

Viele Grüße,

Henk

On 16.06.23 03:09, Kevin Lewi wrote:
> Hi Orie,
>
> Personally, I don't think that we should focus on key formats for the
> core verifiability mechanism -- instead, we should treat the keys as
> opaque blobs which can take on any form, and it is left to the consumer
> of this verifiability mechanism (application layer) to determine what
> format the keys should be stored in, what these keys actually "mean",
> and what claims can be made about the overall system that uses this
> verifiability mechanism.
>
> The exception here would be to address the "standardizing integrations
> of this verifiability mechanism with other protocols" goal, where we
> might indeed have to commit to a specific key format as dictated by the
> other protocols, for example with MLS.
>
> I also don't think we should consider symmetric keys in scope here,
> since the security properties that we would get out of secrecy for the
> values that the identities are bound to is likely going to be quite
> limited. I'd prefer it if we just focused on the public-key scenario, at
> least to start.
> Good questions!
>
> Kevin