Re: [SCITT] [Keytrans] FW: Call for consensus on KEYTRANS

[Orie Steele <[e-mail]>]

As I recall we did discuss key formats, and I was initially hostile to the
idea of not specifying specific key representations that are used within
IETF, for example JWK and COSE Key.

After some discussion, and based on the "cross service interop as a none
goal", it seemed that binding to a specific key format was not necessary,
since unlike SCITT where I might need to make a JWK transparent and then
share it with another transparency service as part of their trust
infrastructure, and they don't want to support every key format under the
sun....

KT receipts are meant to be consumed in a closed ecosystem, where the key
format is chosen by the comsec service provider, and there is no worry
about whether other service providers will need to understand the chosen
format.

See this thread for previous discussion:

-
https://mailarchive.ietf.org/arch/msg/keytrans/9YYciExSfmEJMJg4k5mGLHEOHcQ/
-
https://mailarchive.ietf.org/arch/msg/keytrans/vskxiCbgwTfWBF06v9YGD7x8XmQ/

Regards,

OS

On Fri, Sep 15, 2023 at 6:31 AM Roman Danyliw <[e-mail]> wrote:

> Hi!
>
> It would be beneficial to hear from those hoping to work on KEYTRANS what
> the early thinking might be on binding to specific key formats.
>
> I also appreciate that other WGs, like the ones on which this proposed
> charter is patterned in the space of "end-to-end encrypted communication
> services" (e.g., MLS and MIMI), did not early bind or even mention the
> details of the encoding formats at all in the charter.
>
> Roman
>
> > -----Original Message-----
> > From: Keytrans <[e-mail]> On Behalf Of Henk Birkholz
> > Sent: Monday, July 17, 2023 10:57 AM
> > To: Orie Steele <[e-mail]>; Hannes Tschofenig
> > <[e-mail]>
> > Cc: Roman Danyliw <[e-mail]>; [e-mail]; [e-mail]
> > Subject: Re: [Keytrans] [SCITT] FW: Call for consensus on KEYTRANS
> >
> > Hi keytrans,
> >
> > I'd like to voice an opinion that probably sounds similar to Orie's
> w.r.t. to
> > potentially chartering this WG:
> >
> > * on the one hand, the charter text about work on algorithms and proofs
> (also
> > beyond inclusion & consistency... freshness, for example) seems
> excitingly
> > useful and encouraging
> > * on the other hand, the lack of commitment to a set of 'formats' (I am
> just
> > using that word, I apologize) that are well-established standards in the
> IETF
> > feels like an adoption threshold and rather discouraging.
> >
> > That said, the work of algorithms and proofs is useful enough to charter
> the
> > WG, I think. I am a bit surprised by the lack of interaction with other
> efforts
> > though. I'd have preferred to see a list of common IETF formats, such as
> > provided by Orie, included in the charter text.
> >
> > Viele Grüße,
> >
> > Henk
> >
> > On 17.07.23 16:32, Orie Steele wrote:
> > > I'm active in SCITT, and I joined the KT mailing list and slack
> > > channel and had a few discussions with Richard, Brendan and Kevin.
> > >
> > > My take on why there is no engagement is that it is format preference
> > > related.
> > >
> > > SCITT cares a lot about COSE, and leveraging algorithms that are
> > > defined in CT/KT for COSE.
> > >
> > > KT seems to be more focused on defining algorithms, similar to how CT
> > > defined things.... With no preference towards COSE, or JOSE, or x509.
> > >
> > > At this point, I think it would be fair to say there is interest in
> > > implementing any algorithms KT might define in COSE, but that the work
> > > to do that would probably happen outside of KT... Just like it is
> > > happening outside of SCITT.
> > >
> > > KT seems to have ambitions of being relevant to MLS and MIMI, but
> > > potentially not so much COSE...
> > > Possibly because MLS and MIMI don't depend on COSE.
> > >
> > > I think at a minimum, you would expect "key trans" at IETF to
> > > acknowledge other IETF key representations, but you can imagine that
> > > for KT to be supportive of:
> > >
> > > - application/cose-key
> > > <https://www.iana.org/assignments/media-types/application/cose-key>
> > > - application/jwk+json
> > > <https://www.iana.org/assignments/media-types/application/jwk+json>
> > > - application/pem-certificate-chain
> > > <https://www.iana.org/assignments/media-types/application/pem-certific
> > > ate-chain>
> > > - application/pgp-keys
> > > <https://www.iana.org/assignments/media-types/application/pgp-keys>
> > >
> > > ... etc...
> > >
> > > KT might need to stay at a higher level, and define algorithms without
> > > picking serialization or envelope formats, the way SCITT has.
> > >
> > > ... SCITT chose COSE for good reasons, KT might avoid picking a side
> > > for similarly good reasons.
> > >
> > > Regards,
> > >
> > > OS
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Jul 17, 2023 at 2:13 AM Hannes Tschofenig
> > > <[e-mail] <mailto:[e-mail]>> wrote:
> > >
> > >     Hi Roman, Hi all,
> > >
> > >
> > >     there is one aspect that puzzles me: repeated attempts to involve
> > >     KEYTRANS participants into a discussion with the SCITT group have
> been
> > >     not been successful.
> > >
> > >
> > >     It appears to be a low-hanging fruit to reach out to a group that
> is
> > >     working on a very similiar problem / where there is an obvious
> overlap.
> > >
> > >
> > >     Ciao
> > >
> > >     Hannes
> > >
> > >
> > >     Am 10.07.2023 um 19:14 schrieb Roman Danyliw:
> > >      > Hi MLS and SCITT WGs!
> > >      >
> > >      > Cross posting to raise visibility given the discussion of key
> > >     transparency on the SCITT mailing list and the promise of MLS
> > >     integration in the proposed KEYTRANS charter.
> > >      >
> > >      > Please respond to the KEYTRANS@ietf list by Thursday, July 13th
> > >     with feedback on the proposed charter.  See
> > >     https://datatracker.ietf.org/doc/charter-ietf-keytrans/00-05/
> > >     <https://datatracker.ietf.org/doc/charter-ietf-keytrans/00-05/>.
> > >     This will help chart the next steps.
> > >      >
> > >      > Thanks,
> > >      > Roman
> > >      >
> > >      > -----Original Message-----
> > >      > From: Roman Danyliw
> > >      > Sent: Thursday, June 29, 2023 2:35 PM
> > >      > To: [e-mail] <mailto:[e-mail]>
> > >      > Subject: Call for consensus on KEYTRANS
> > >      >
> > >      > Hi!
> > >      >
> > >      > At IETF 116, the initial BoF on KEYTRANS was convened [1].  The
> > >     meeting provided a strong consensus signal around a well-defined
> > >     problem being presented and IETF interest in solving it.  There
> also
> > >     appeared to a critical mass of energy to do the work (write and
> > >     review drafts).  The next step was to produce a draft charter to
> > >     more concretely capture a defined WG scope.
> > >      >
> > >      > In recent months there have been a few charter versions and
> > >     robust discussion on their contents.  As we approach final planning
> > >     for IETF 117, I'd like to assess where we stand with a formal
> > >     consensus check with the charter.  Please see
> > >     https://datatracker.ietf.org/doc/charter-ietf-keytrans/00-04/
> > >     <https://datatracker.ietf.org/doc/charter-ietf-keytrans/00-04/>
> > >     (00-04) and respond to the list by Thursday, July 13 (two weeks
> from
> > >     now):
> > >      >
> > >      > ==[ consensus check questions ]==
> > >      > (1) Do you support the charter text? Or do you have objections
> or
> > >     blocking concerns (please describe what they might be)?
> > >      >
> > >      > If you do support the charter text:
> > >      > (2) Are you willing to author or participate in the developed of
> > >     the WG drafts?
> > >      >
> > >      > (3) Are you willing to review the WG drafts?
> > >      >
> > >      > (4) Are you interested in implementing the WG drafts?
> > >      >
> > >      > ==[ consensus check questions ]==
> > >      >
> > >      > If you previously spoke up at the BoF, please repeat yourself
> here.
> > >      >
> > >      > The outcome of this consensus check will inform how to planned
> > >     for the second KEYTRANS BoF scheduled at IETF 117.  Options
> include:
> > >      >
> > >      > ** If we find consensus on the mailing with the current charter
> > >     text, no BoF is needed, and it will be canceled (note: this should
> > >     be viewed as a success.  The entire point of the BoF is to produce
> a
> > >     charter and that goal would have been realized)
> > >      >
> > >      > ** If there are blocking concerns which cannot be resolved on
> the
> > >     mailing list, these will form the basis of the IETF 117 BoF agenda
> > >      >
> > >      > Thanks,
> > >      > Roman
> > >      >
> > >      > [1] https://datatracker.ietf.org/doc/agenda-116-keytrans/
> > >     <https://datatracker.ietf.org/doc/agenda-116-keytrans/>
> > >
> > >     --
> > >     SCITT mailing list
> > >     [e-mail] <mailto:[e-mail]>
> > >     https://www.ietf.org/mailman/listinfo/scitt
> > >     <https://www.ietf.org/mailman/listinfo/scitt>
> > >
> > >
> > >
> > > --
> > >
> > >
> > > ORIE STEELE
> > > Chief Technology Officer
> > > www.transmute.industries
> > >
> > > <https://transmute.industries>
> > >
> > >
> >
> > --
> > Keytrans mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/keytrans
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>