Hi Andrea,
> to avoid the only option available today:
That wonders me. I think, what is more in question is the comparison
of the new certficate type with the two currently used ones (x509 and
Raw Public Key). Reading your link, my first impression is, that this
is pretty similar to x509 but in json. So talking about "only option"
seems to be a little over done.
best regards
Achim
Am 05.04.24 um 12:12 schrieb Andrea Vesco:
Hi Hannes, thanks for your question.
We are referring to a (well-resourced) IoT system with edge computing nodes. In
the IoT/edge segment, the VC can be used for mutual authentication directly in
TLS to avoid the only option available today: first establish a TLS channel
with X.509 based server-only authentication and, second, authenticate the
client with its VC on top of the TLS channel. The Client authentication at the
application layer works well, but in our opinion, only in web scenarios.
In addition, using the client_certificate_type and server_certificate_type
extensions would also enable the option of hybrid (VC - X.509) mutual
authentication in the edge/cloud segment at the TLS layer.
In our opinion, this is an incremental approach to support the adoption of VC
and DID technologies in IoT systems.
Best, Andrea
On 4 Apr 2024, at 12:29, hannes.tschofe...@gmx.net wrote:
Hi Andrea,
Thanks for sharing the info.
Could you say a bit more about your IoT use case?
Ciao
Hannes
-----Original Message-----
From: TLS <tls-boun...@ietf.org> On Behalf Of Andrea Vesco
Sent: Donnerstag, 4. April 2024 10:53
To: tls@ietf.org
Subject: [TLS] I-D on TLS authentication with VC
L. Perugini and I have written an I-D on the use of Verifiable Credentials
[1][2] as an additional authentication mode in TLS. We presented the I-D to
the ALLDISPATCH WG during IETF119 and the outcome was to explore the potential
interest of the TLS WG. The I-D proposes to add (i) a new Certificate Type
called VC in addition to X509 and RawPublicKey to the existing
client_certificate_type and server_certificate_type extensions and (ii) a new
extension called did_methods to carry the list of DID Methods supported by the
endpoint to resolve the peer's DID during the validation of the Verifiable
Credential. The I-D focuses on the IoT use case.
We are aware of the current discussion in the working group about new code
points and would like to know your opinion in the case of this I-D and to
explore the possible interest. Thank you in advance for your feedback.
I-D: https://datatracker.ietf.org/doc/draft-vesco-vcauthtls/
Code:
- Provider https://github.com/Cybersecurity-LINKS/openssl-ssi-provider
- OpenSSL https://github.com/Cybersecurity-LINKS/openssl
[1] https://www.w3.org/TR/vc-data-model-2.0/
[2] https://www.w3.org/TR/did-core/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
