Re: [Uta] New I-D on VC and TLS

Orie Steele <orie@transmute.industries> Tue, 20 February 2024 13:26 UTC

Return-Path: <orie@transmute.industries>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAC9C1519A6 for <uta@ietfa.amsl.com>; Tue, 20 Feb 2024 05:26:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCTOki-3a50X for <uta@ietfa.amsl.com>; Tue, 20 Feb 2024 05:26:09 -0800 (PST)
Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6E32C151088 for <uta@ietf.org>; Tue, 20 Feb 2024 05:25:27 -0800 (PST)
Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-299566373d4so1921001a91.1 for <uta@ietf.org>; Tue, 20 Feb 2024 05:25:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1708435527; x=1709040327; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mLLSr7mvJfTPn+jS+J6pNQtKoel12YtUdFoNvYCPP3k=; b=Rs4B/5Y0fpYbQWp+xjg08dYs6Ig/cU4cIKGSniDgEoUTxGBr+iJqL0NeU5x+7smOWl 8Dok4cbidgjDm4xmVQof/16lFYcu3yqKVhikhQ7GU9YcNu5Ph4W94gUkapFBAZFXScqC Ta2FBpQKBfMCdJzFDgXjxi7mAXwDVZ8LeSRnM7h34Npx3I4QWLdmW1oSYAljUDfhT3Hv PYPEQRQO8KeaZw/i5PpQPOxq0Z8jK1UCqvmfyLqXEIqs42SEVDSurxnDYjev4nDlQAVu MIOGlJ3j7+i0VS0zd+bf+hz+fFMZ2ZfO9SnnfvoP8JUvHLXIKAlRRUE6I5RkJTMVTcdV gu/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708435527; x=1709040327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mLLSr7mvJfTPn+jS+J6pNQtKoel12YtUdFoNvYCPP3k=; b=suSXyqk+qvxh1KgHVsSuEIRrfHOAY/DJHzYZEgOWxFNzRJUZHLI8gPxtbCh6wN63e6 tMvmkGoImovlOkf3V8YAeWSZj8gurZ+YNzeTPBAsJr1Zn5ERKvXly2bX9JNdp3VOtn65 nYEWnDzZdZmG1cui2nNkjApao+0cXBPYJCNf/BwV6WMXz/Fkz2b5V6hXet5DEZYSMI4m S4aCNr4w4RfeUJfm85eTkxlzb1tyoHPuRQRqYLPPRYW6rjE/aJuyuggRonH/WM2ueSHu jbgFNYjMWDaAiokNpv4Xb08mci4A6AEgdlAJblqwZg1+WF0K+3lvjIpyiSLg+3nqUMCD ggzA==
X-Forwarded-Encrypted: i=1; AJvYcCWyusCOvwTbbnpTbBpE2LOI7wcfEBWzD7GAR8ORMVSbCrxcwJ+RGVjuVDQAozx257wAmDKJgYndGoMsRek=
X-Gm-Message-State: AOJu0YztkSHw5qS3HV+ZpevkNFiKGztdpbtXR09kqCntyIMh2cK179NJ Rks30AwWNwjBpczw/AsAAPf01vZw4SKRLcIlQ+G/MGNLifgb+nXKMhH7fppxMhy9NhWlxxcWh4A 612PpCkHdDV7YIS+kuuFdAMxBksv35AuherSmYimPlgBexaYy8Y9mSQ==
X-Google-Smtp-Source: AGHT+IGG90S78lZIKPqnfkYpNyRwFl3hZLPVN/l2POggkQ2tmZFAg3hk0i8EJgQshRyCTVZuRqslokaPBD690a3KCrA=
X-Received: by 2002:a17:90b:1094:b0:299:1c53:113f with SMTP id gj20-20020a17090b109400b002991c53113fmr12610702pjb.0.1708435527155; Tue, 20 Feb 2024 05:25:27 -0800 (PST)
MIME-Version: 1.0
References: <D3F7994C-B82F-4890-8EB0-0BBBE3D7D608@linksfoundation.com> <e0a27c12cc1d456c9194a1dc3ea85513@huawei.com> <D4E6E6A5-0192-4C45-B8B0-204C03F2E41B@linksfoundation.com>
In-Reply-To: <D4E6E6A5-0192-4C45-B8B0-204C03F2E41B@linksfoundation.com>
From: Orie Steele <orie@transmute.industries>
Date: Tue, 20 Feb 2024 07:25:15 -0600
Message-ID: <CAN8C-_KSJ_Cu1RiiRP67KFAm1JpPG4ntaKZJhYRF2-G28ZMuKg@mail.gmail.com>
To: Andrea Vesco <andrea.vesco@linksfoundation.com>
Cc: "Yanlei(Ray)" <ray.yanlei@huawei.com>, "uta@ietf.org" <uta@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b7dc8b0611d024ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/NOu2HvmlrzDbP4m8tRO1a0WsYmg>
Subject: Re: [Uta] New I-D on VC and TLS
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Feb 2024 13:26:13 -0000

Chair hat off,

I'm not sure if authors will agree with this characterization, but I will
give it anyway, and authors can correct me:

Why use VCs?
Because of the CBOR toolchain.
You should comment on if the payload is JSON-LD, if it is, then you lose
most of the value of CBOR in my view.

Why use DIDs?
Alternative PKI, similar to "let's encrypt" or a private pki...

More of the interesting part comes from "properties of different PKIs",
which translate to "properties of DID Methods" in this document.
It's worth being upfront about the energy cost / censorship trade offs for
the different possible solutions here.

There is also a phenomenon in "blockchain (aka verifiable data registry)"
where infrastructure can be single use or multi-use.

In the case that a specific ledger is used for payments, it can also be
used for key distribution, or routing, for example:
https://datatracker.ietf.org/doc/draft-mcbride-rtgwg-bgp-blockchain/

Of course this draft is not about payments or routing, but it is about key
distribution and TLS, and delivering those capabilities alongside places
that might already rely on a specific technology for routing or payments...
at least that is how I see it :)

Regards,

OS







On Tue, Feb 20, 2024 at 2:51 AM Andrea Vesco <
andrea.vesco@linksfoundation.com> wrote:

> Thanks for the comment. The I-D describes how to add VCs as a certificate
> type in TLS while maintaining the interoperability with other certificates.
> The aim is to move SSI-based authentication from the application layer down
> to TLS without changing the way SSI and TLS work. The SSI model (based on
> the use of VC [0] and DIDs [1]) specifies the use of DLT (or more generally
> Verifiable Data Registry) to store and retrieve public keys. We will
> clarify this point in the abstract and introduction of the next version.
>
> Andrea Vesco
>
> [0] https://www.w3.org/TR/vc-data-model-2.0/
> [1] https://www.w3.org/TR/did-core/
>
>
> > On 19 Feb 2024, at 13:40, Yanlei(Ray) <ray.yanlei@huawei.com> wrote:
> >
> > The motivation for your design needs to be described in the draft.
> > Why do you want to put the public key in the distributed ledger?
> >
> > Lei YAN
> >
> > -----Original Message-----
> > From: Uta <uta-bounces@ietf.org> On Behalf Of Andrea Vesco
> > Sent: Monday, February 19, 2024 4:57 PM
> > To: uta@ietf.org
> > Subject: [Uta] New I-D on VC and TLS
> >
> > L.Perugini and I have written an I-D on the use of Verifiable Credential
> (VC) as a new means of authentication in TLS.  We think it might be of
> interest and in the scope of the UTA WG.
> >
> > Could you please give us your opinion?
> >
> > Draft
> > Datatracker https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/
> > Github https://github.com/Cybersecurity-LINKS/draft-vesco-vcauthtls
> >
> > Kind Regards,
> > Andrea Vesco
> > _______________________________________________
> > Uta mailing list
> > Uta@ietf.org
> > https://www.ietf.org/mailman/listinfo/uta
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>