MIME-Version: 1.0
References: <684C0632-DB8D-45DE-8DDB-AED6785B9AA3@edvina.net>
In-Reply-To: <684C0632-DB8D-45DE-8DDB-AED6785B9AA3@edvina.net>
From: Orie Steele <orie@transmute.industries>
Date: Tue, 13 Aug 2024 07:39:22 -0500
Message-ID: 
 <CAN8C-_J+Uk9H3fKbPLXM4iaMU1aoK+O=TR+o1NiOvug2MxzwCA@mail.gmail.com>
To: "Olle E. Johansson" <oej@edvina.net>
Content-Type: multipart/alternative; boundary="000000000000eb80b4061f8fe63c"
Message-ID-Hash: H4SXLPFLSPTYIWYLUWWN4MOGC5RM4BSW
CC: scitt <scitt@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BSCITT=5D_Re=3A_Distributing_a_transparency_statement_in_TEA?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/scitt/mt9DVhe4leEEZSPXIRGNf9D41pE>

--000000000000eb80b4061f8fe63c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Olle E. Johansson <oej@edvina.net> wr=
ote:

> Hi!
>
> Thank you for a good meeting yesterday!
>
> I=E2=80=99ve tried to read up on the drafts and the presentations availab=
le.
>
> 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 (=E2=80=9Cstatement=E2=80=9D) 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=E2=80=99t want to maintain a speci=
fic 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=E2=80=99s 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 stor=
e
> doesn=E2=80=99t scale much. I do think that DANE and DANCE may have a rol=
e 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 terminolog=
y
> and make sure that there is compatibility.
>
> Cheers from a sunny Sweden!
>
> /O
> --
> SCITT mailing list -- scitt@ietf.org
> To unsubscribe send an email to scitt-leave@ietf.org
>

--000000000000eb80b4061f8fe63c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I&#39;ve been exploring putting cose-key and cwt thumbpri=
nts in TLSA records.<div dir=3D"auto"><br></div><div dir=3D"auto">This help=
s you confirm that a specific domain recognizes a key as confirmation metho=
d for credentials.</div><div dir=3D"auto"><br></div><div dir=3D"auto">You w=
ould probably want a draft that registered the proper bits for recognizing =
cnf thumbprints, and to update the associated registries.</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">You still need key distribution though, D=
ANE just helps you confirm a thumbprint is bound to a domain.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">It would still might be an improvemen=
t 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.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">OS</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br=
></div><div dir=3D"auto"><br></div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 13, 2024, 6:49=E2=80=AFAM Ol=
le E. Johansson &lt;<a href=3D"mailto:oej@edvina.net">oej@edvina.net</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
Thank you for a good meeting yesterday!<br>
<br>
I=E2=80=99ve tried to read up on the drafts and the presentations available=
.<br>
<br>
A few issues came up in my head :-) :<br>
<br>
* Relation between a transparency statement and the issuer/signer<br>
<br>
If a SCITT ts is distributed separately and the relaying party wants to ver=
ify with the log - is there any way to discover a path to the transparency =
log API from the actual statement?<br>
<br>
* Transparency artefact (=E2=80=9Cstatement=E2=80=9D) types<br>
In the use cases you have a non-normative list of various artefacts that ma=
y be used in statements.<br>
We have the same issue in TEA - we don=E2=80=99t want to maintain a specifi=
c list. If I understand it right you simply use media-type in the SCITT sta=
tement - am I right in that or will that list be used in any other way?<br>
<br>
For statements that are more generic, let=E2=80=99s say a PDF file with a s=
tatement of conformity with an EU law - application/PDF will not be very us=
eful. I think we need some extra attribute or a registry to handle this. Wh=
at do you think?<br>
<br>
* Digital signatures on objects<br>
<br>
I strongly think we have to have a PKI discussion. Your trust anchor store =
doesn=E2=80=99t scale much. I do think that DANE and DANCE may have a role =
to play here to provide more scalabilty.<br>
<br>
To summarize: I think that there are plenty of ways TEA will co-work with S=
CITT and there are areas we can work together to use the same terminology a=
nd make sure that there is compatibility.<br>
<br>
Cheers from a sunny Sweden!<br>
<br>
/O<br>
-- <br>
SCITT mailing list -- <a href=3D"mailto:scitt@ietf.org" target=3D"_blank" r=
el=3D"noreferrer">scitt@ietf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:scitt-leave@ietf.org" tar=
get=3D"_blank" rel=3D"noreferrer">scitt-leave@ietf.org</a><br>
</blockquote></div>

--000000000000eb80b4061f8fe63c--