[SCITT] Re: Distributing a transparency statement in TEA

[Orie Steele <[e-mail]>]

I've been exploring putting cose-key and cwt thumbprints in TLSA records.

This helps you confirm that a specific domain recognizes a key as
confirmation method for credentials.

You would probably want a draft that registered the proper bits for
recognizing cnf thumbprints, and to update the associated registries.

You still need key distribution though, DANE just helps you confirm a
thumbprint is bound to a domain.

It would still might be an improvement for notaries and code signing
services, especially if attackers needed to update the DNS in order to get
a new key recognized, or if updates to DNS could be used to revoke
compromised keys.

OS




On Tue, Aug 13, 2024, 6:49 AM Olle E. Johansson <[e-mail]> wrote:

> Hi!
>
> Thank you for a good meeting yesterday!
>
> I’ve tried to read up on the drafts and the presentations available.
>
> A few issues came up in my head :-) :
>
> * Relation between a transparency statement and the issuer/signer
>
> If a SCITT ts is distributed separately and the relaying party wants to
> verify with the log - is there any way to discover a path to the
> transparency log API from the actual statement?
>
> * Transparency artefact (“statement”) types
> In the use cases you have a non-normative list of various artefacts that
> may be used in statements.
> We have the same issue in TEA - we don’t want to maintain a specific list.
> If I understand it right you simply use media-type in the SCITT statement -
> am I right in that or will that list be used in any other way?
>
> For statements that are more generic, let’s say a PDF file with a
> statement of conformity with an EU law - application/PDF will not be very
> useful. I think we need some extra attribute or a registry to handle this.
> What do you think?
>
> * Digital signatures on objects
>
> I strongly think we have to have a PKI discussion. Your trust anchor store
> doesn’t scale much. I do think that DANE and DANCE may have a role to play
> here to provide more scalabilty.
>
> To summarize: I think that there are plenty of ways TEA will co-work with
> SCITT and there are areas we can work together to use the same terminology
> and make sure that there is compatibility.
>
> Cheers from a sunny Sweden!
>
> /O
> --
> SCITT mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>