[TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

2023-10-19 Thread David Benjamin
Hi all,

We just published a document on certificate negotiation. It's a TLS
extension, which allows the client to communicate which trust anchors it
supports, primarily focused on use cases like the Web PKI where trust
stores are fairly large. There is also a supporting ACME extension, to
allow CAs to provision multiple certificate chains on a server, with enough
metadata to match against what the client sends. (It also works in the
other direction for client certificates.)

The hope is this can build towards a more agile and flexible PKI. In
particular, the Use Cases section of the document details some scenarios
(e.g. root rotation) that can be made much more robust with it.

It's very much a draft-00, but we're eager to hear your thoughts on it!

David, Devon, and Bob

-- Forwarded message -
From: 
Date: Thu, Oct 19, 2023 at 11:36 AM
Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt
To: Bob Beck , David Benjamin , Devon
O'Brien 


A new version of Internet-Draft draft-davidben-tls-trust-expr-00.txt has
been
successfully submitted by David Benjamin and posted to the
IETF repository.

Name: draft-davidben-tls-trust-expr
Revision: 00
Title:TLS Trust Expressions
Date: 2023-10-19
Group:Individual Submission
Pages:35
URL:
https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt
Status:   https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/
HTML:
https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr


Abstract:

   This document defines TLS trust expressions, a mechanism for relying
   parties to succinctly convey trusted certification authorities to
   subscribers by referencing named and versioned trust stores.  It also
   defines supporting mechanisms for subscribers to evaluate these trust
   expressions, and select one of several available certification paths
   to present.  This enables a multi-certificate deployment model, for a
   more agile and flexible PKI that can better meet security
   requirements.



The IETF Secretariat
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

2023-10-19 Thread Ilari Liusvaara
On Thu, Oct 19, 2023 at 11:38:33AM -0400, David Benjamin wrote:
> Hi all,
> 
> We just published a document on certificate negotiation. It's a TLS
> extension, which allows the client to communicate which trust anchors it
> supports, primarily focused on use cases like the Web PKI where trust
> stores are fairly large. There is also a supporting ACME extension, to
> allow CAs to provision multiple certificate chains on a server, with enough
> metadata to match against what the client sends. (It also works in the
> other direction for client certificates.)
> 
> The hope is this can build towards a more agile and flexible PKI. In
> particular, the Use Cases section of the document details some scenarios
> (e.g. root rotation) that can be made much more robust with it.
> 
> It's very much a draft-00, but we're eager to hear your thoughts on it!

Some quick thoughts:

- The multiple certificates from one ACME order really scares me. It
  seems to me that can lead to all sorts of trouble.
- If there can be only one certificate, one could send all the chains
  in one go via fist sending the certificate, then issuer chains each
  ended by entry describing the trust anchor.
- The latest version and previous version stuff seems pretty confusing
  to me.
- I am not sure this is useful for the client->server direction.



What I think is a simpler version that might work:


Information from root program to CA:

- Root program name.
- For each trust anchor:
  * Trust anchor certificate.
  * First version TA appeared in.
  * Expiry time
  * List of indices.

Indices can be reused after all TAs using those have expired.


Information from CA to TLS server for each TA:

- For each root program:
  * Root program name
  * The first version TA appeared in.
  * List of indices.

CA MUST NOT include entries that expire before the certificate.


Information from TLS client to TLS server:

- Root program name.
- Root program version.
- List of revoked indices.

The revoked indices specifies TAs that have been recently removed
before expiry (there could still be unexpired certificates out
there).


Chain is usable if it includes an entry where:
 
a) Root program name matches, AND
b) Root program version is at least the first version, AND
c) Intersection of indices and revoked indices is empty.

If TLS server has multiple configured certificates, it should skip ones
that have no usable chains. If no certificate has usable chain, it
should act like the extension was not sent.



> -- Forwarded message -
> From: 
> Date: Thu, Oct 19, 2023 at 11:36 AM
> Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt
> To: Bob Beck , David Benjamin , Devon
> O'Brien 
> 
> Name: draft-davidben-tls-trust-expr
> Revision: 00
> Title:TLS Trust Expressions
> Date: 2023-10-19
> Group:Individual Submission
> Pages:35
> URL:
> https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/
> HTML:
> https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr
 



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


[TLS] I-D Action: draft-ietf-tls-rfc8447bis-05.txt

2023-10-19 Thread internet-drafts
Internet-Draft draft-ietf-tls-rfc8447bis-05.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   IANA Registry Updates for TLS and DTLS
   Authors: Joe Salowey
Sean Turner
   Name:draft-ietf-tls-rfc8447bis-05.txt
   Pages:   17
   Dates:   2023-10-19

Abstract:

   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-05.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-05

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls