diff --git a/draft-vesco-vcauthtls.html b/draft-vesco-vcauthtls.html index dc1934b..583f5ad 100644 --- a/draft-vesco-vcauthtls.html +++ b/draft-vesco-vcauthtls.html @@ -1140,91 +1140,79 @@

1. Introduction

-

W3C defined VC

+

W3C defined VC and DID

+

How to create identity in SSI and how to verify the VP (in HS sections describe how the hs covers the VP presentation).

@@ -1249,234 +1238,206 @@

appear in all capitals, as shown here.

-
+
-

-3. VC Certificate type +

+3. Extensions

-
+
+
+

+3.1. VC Certificate Type +

+

The TLS extensions "client_certificate_type" and "server_certificate_type" [RFC7250] are used to negotiate the type of Certificate messages used in TLS to authenticate the server and, optionally, the client. Using separate extensions allows for mixed deployments where the client and server can use certificates of different types. +~~~ + /* Managed by IANA */ + enum { + X509(0), + RawPublicKey(2), + VC(224), + (255) + } CertificateType;

+

struct { + select(certificate_type){ + // The new certificate type defined in this document + case VC: + opaque cert_data<1..2^24-1>;

+
-opaque ASN.1Cert<1..2^24-1>;
-
-struct {
-   select(certificate_type){
-      // RawPublicKey certificate type defined in RFC 7250
-      case RawPublicKey:
-         opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;
-
-      // X.509 certificate defined in RFC 5246
-      case X.509:
-         ASN.1Cert certificate_list<0..2^24-1>;
+     // RawPublicKey certificate type defined in RFC 7250
+     case RawPublicKey:
+        opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
 
-      // The new certificate type definied in this document
-      case VC:
-         opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;
+     // X.509 certificate defined in RFC 5246
+     case X509:
+        opaque cert_data<1..2^24-1>;
 
-      // Additional certificate type based on
-      // "TLS Certificate Types" subregistry
-   };
-} Certificate;
-
+ // Additional certificate type based on + // "TLS Certificate Types" subregistry + }; } Certificate; ~~~ +
-

TLS Certificate types (IANA)

- - - - - - - - - - - - - - - - - - - - -
Table 1
valuenamerecommendedReferencecomment
4Verifiable Credential This document 
-
-
-

-4. Structure of the FOOBAR Extensions -

- -
-
-

-4.2. foobar1 -

-
-
-

-4.3. foobar2 -

-
+
+
+

+4. did_methods extension +

+
+
+   /* Managed by IANA */
+   enum {
+      iota(0),
+      ..
+      (65535)
+   } DIDMethod
+
+   struct {
+      DIDMethod did_methods<2..2^16-2>
+   } DIDMethodList
+
+   [did-registry](https://www.w3.org/TR/did-spec-registries/#did-methods)
+
+

did_methods extension could be sent only in ClientHello and CertificateRequest messages.

-
+ -
-
+

-8. Examples +7. Examples

-
+

-8.4. TLS Client Uses Certificate and Server Uses VP +7.4. TLS Client Uses Certificate and Server Uses VP

-

it happens when the server does not send ssi_paramters extension in certificate request or it does but the client does not have a DID in the list of supported DLT (i.e. DID Methods) by the server

+

it happens when the server does not send ssi_paramters extension in certificate request or it does but the client does not have a DID in the list of supported DLT (i.e. DID Methods) by the server

-
+

-8.5. Fallback to Traditional Handshake +7.5. Fallback to Traditional Handshake

-

server ignores ssi_parameters extension in the clientHello

+

server ignores ssi_parameters extension in the clientHello

-
+

-8.6. Empty intersection of Client and Server DID Methods +7.6. Empty intersection of Client and Server DID Methods

-

HelloRetryRequest + foobar extension -server replies with the list of its DID Methods, this implies that the server has a DID stored in each of the DLT of the listed DID Methods.

+

HelloRetryRequest + foobar extension +server replies with the list of its DID Methods, this implies that the server has a DID stored in each of the DLT of the listed DID Methods.

-
+

-8.7. TLS Server Enforces SSI Server Authentication +7.7. TLS Server Enforces SSI Server Authentication

-

server enforces SSI client authentication (no fall back bu enforce SSI to the client)

-

HelloRetryRequest

+

server enforces SSI client authentication (no fall back bu enforce SSI to the client)

+

HelloRetryRequest

-
+

-9. Security Considerations +8. Security Considerations

-

TODO Security

+

TODO Security

-
+

-10. IANA Considerations +9. IANA Considerations

-

This document has no IANA actions.

+

This document has no IANA actions.

-
+

-11. Normative References +10. Normative References

-

[DID] W3C, Decentralized Identifiers (DIDs) v1.0. Core architecture, data model, and representations. W3C Recommendation, 2022. https://www.w3.org/TR/did-core/

-

[VC] W3C, Verifiable Credentials Data Model v2.0. W3C Recommendation, 2023. https://www.w3.org/TR/vc-data-model-2.0/

+

[DID] W3C, Decentralized Identifiers (DIDs) v1.0. Core architecture, data model, and representations. W3C Recommendation, 2022. https://www.w3.org/TR/did-core/

+

[VC] W3C, Verifiable Credentials Data Model v2.0. W3C Recommendation, 2023. https://www.w3.org/TR/vc-data-model-2.0/

-
+

-13. Normative References +12. Normative References

[RFC2119]
diff --git a/draft-vesco-vcauthtls.txt b/draft-vesco-vcauthtls.txt index 1cf7ceb..619120b 100644 --- a/draft-vesco-vcauthtls.txt +++ b/draft-vesco-vcauthtls.txt @@ -68,37 +68,36 @@ Table of Contents 1. Introduction 2. Conventions and Definitions - 3. VC Certificate type - 4. Structure of the FOOBAR Extensions - 4.1. ssi_parameters - 4.2. foobar1 - 4.3. foobar2 - 5. Possibly the new Messages - 6. TLS Client and Server Handshake Behavior - 6.1. ClientHello - 6.2. CertificateRequest - 6.3. Certificate - 6.4. CertificateVerify - 7. An alternative Design / Design Consideration - 8. Examples - 8.1. TLS Server Uses a VP - 8.2. TLS Client and Server Use VPs - 8.3. TLS Client Uses VP and Server Uses Certificate - 8.4. TLS Client Uses Certificate and Server Uses VP - 8.5. Fallback to Traditional Handshake - 8.6. Empty intersection of Client and Server DID Methods - 8.7. TLS Server Enforces SSI Server Authentication - 9. Security Considerations - 10. IANA Considerations - 11. Normative References - 12. Informative References - 13. Normative References + 3. Extensions + 3.1. VC Certificate Type + 4. did_methods extension + 5. TLS Client and Server Handshake + 5.1. ClientHello + 5.2. CertificateRequest + 5.3. Certificate + 6. An alternative Design / Design Consideration + 7. Examples + 7.1. TLS Server Uses a VP + 7.2. TLS Client and Server Use VPs + 7.3. TLS Client Uses VP and Server Uses Certificate + 7.4. TLS Client Uses Certificate and Server Uses VP + 7.5. Fallback to Traditional Handshake + 7.6. Empty intersection of Client and Server DID Methods + 7.7. TLS Server Enforces SSI Server Authentication + 8. Security Considerations + 9. IANA Considerations + 10. Normative References + 11. Informative References + 12. Normative References Acknowledgments Authors' Addresses 1. Introduction - W3C defined VC + W3C defined VC and DID + + How to create identity in SSI and how to verify the VP (in HS + sections describe how the hs covers the VP presentation). 2. Conventions and Definitions @@ -108,102 +107,101 @@ Table of Contents BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. -3. VC Certificate type - - opaque ASN.1Cert<1..2^24-1>; - - struct { - select(certificate_type){ - // RawPublicKey certificate type defined in RFC 7250 - case RawPublicKey: - opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; - - // X.509 certificate defined in RFC 5246 - case X.509: - ASN.1Cert certificate_list<0..2^24-1>; +3. Extensions - // The new certificate type definied in this document - case VC: - opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; +3.1. VC Certificate Type - // Additional certificate type based on - // "TLS Certificate Types" subregistry - }; - } Certificate; + The TLS extensions "client_certificate_type" and + "server_certificate_type" [RFC7250] are used to negotiate the type of + Certificate messages used in TLS to authenticate the server and, + optionally, the client. Using separate extensions allows for mixed + deployments where the client and server can use certificates of + different types. ~~~ /* Managed by IANA */ enum { X509(0), + RawPublicKey(2), VC(224), (255) } CertificateType; - TLS Certificate types (IANA) + struct { select(certificate_type){ // The new certificate type + defined in this document case VC: opaque cert_data<1..2^24-1>; - +=======+=======================+=============+===========+=========+ - | value | name | recommended | Reference | comment | - +=======+=======================+=============+===========+=========+ - | 4 | Verifiable | | This | | - | | Credential | | document | | - +-------+-----------------------+-------------+-----------+---------+ + // RawPublicKey certificate type defined in RFC 7250 + case RawPublicKey: + opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; - Table 1 + // X.509 certificate defined in RFC 5246 + case X509: + opaque cert_data<1..2^24-1>; -4. Structure of the FOOBAR Extensions + // Additional certificate type based on + // "TLS Certificate Types" subregistry + }; } Certificate; ~~~ -4.1. ssi_parameters +4. did_methods extension -4.2. foobar1 + /* Managed by IANA */ + enum { + iota(0), + .. + (65535) + } DIDMethod -4.3. foobar2 + struct { + DIDMethod did_methods<2..2^16-2> + } DIDMethodList -5. Possibly the new Messages + [did-registry](https://www.w3.org/TR/did-spec-registries/#did-methods) -6. TLS Client and Server Handshake Behavior + did_methods extension could be sent only in ClientHello and + CertificateRequest messages. -6.1. ClientHello +5. TLS Client and Server Handshake -6.2. CertificateRequest +5.1. ClientHello -6.3. Certificate +5.2. CertificateRequest -6.4. CertificateVerify +5.3. Certificate -7. An alternative Design / Design Consideration +6. An alternative Design / Design Consideration -8. Examples +7. Examples -8.1. TLS Server Uses a VP +7.1. TLS Server Uses a VP -8.2. TLS Client and Server Use VPs +7.2. TLS Client and Server Use VPs -8.3. TLS Client Uses VP and Server Uses Certificate +7.3. TLS Client Uses VP and Server Uses Certificate -8.4. TLS Client Uses Certificate and Server Uses VP +7.4. TLS Client Uses Certificate and Server Uses VP it happens when the server does not send ssi_paramters extension in certificate request or it does but the client does not have a DID in the list of supported DLT (i.e. DID Methods) by the server -8.5. Fallback to Traditional Handshake +7.5. Fallback to Traditional Handshake server ignores ssi_parameters extension in the clientHello -8.6. Empty intersection of Client and Server DID Methods +7.6. Empty intersection of Client and Server DID Methods HelloRetryRequest + foobar extension server replies with the list of its DID Methods, this implies that the server has a DID stored in each of the DLT of the listed DID Methods. -8.7. TLS Server Enforces SSI Server Authentication +7.7. TLS Server Enforces SSI Server Authentication server enforces SSI client authentication (no fall back bu enforce SSI to the client) HelloRetryRequest -9. Security Considerations +8. Security Considerations TODO Security -10. IANA Considerations +9. IANA Considerations This document has no IANA actions. -11. Normative References +10. Normative References [DID] W3C, Decentralized Identifiers (DIDs) v1.0. Core architecture, data model, and representations. W3C Recommendation, 2022. @@ -212,9 +210,9 @@ Table of Contents [VC] W3C, Verifiable Credentials Data Model v2.0. W3C Recommendation, 2023. https://www.w3.org/TR/vc-data-model-2.0/ -12. Informative References +11. Informative References -13. Normative References +12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119,