This is most of what's needed. Plus something along the lines of:
In some cases the user should be able to accept the certificate in
question as valid also for subsequent connections. Such ad-hoc
"pinning" should typically not restrict future connections to just
On Wed, Sep 08, 2021 at 04:45:24PM +, Salz, Rich wrote:
> >Perhaps the text can be made more concise, but I don't think full
> removal is warranted. This is *not* the fragile key pinning from HPKP.
>
> Right now the text has this. Is more needed?
>
> ### Failure: No Match Found
>
>
>Perhaps the text can be made more concise, but I don't think full
removal is warranted. This is *not* the fragile key pinning from HPKP.
Right now the text has this. Is more needed?
### Failure: No Match Found
If the client does not find a presented identifier matching any of the
refe
On Wed, Sep 08, 2021 at 03:52:23PM +, Salz, Rich wrote:
> I would like to remove the discussion of pinning from 5126bis for the
> following reason:
[ You surely meant 6125, but let your fingers do the talking... ]
>
> * It’s an escape hatch, saying “do all these things but if you don’t
I would like to remove the discussion of pinning from 5126bis for the following
reason:
* It’s an escape hatch, saying “do all these things but if you don’t get a
match, you can pin.”
* The current wording allows its use, anyway.
* Pinning is bad.
A proposed change is in
https://g
I merged the PR’s and draft-02 is now available at
https://www.ietf.org/id/draft-ietf-uta-rfc6125bis-02.html, etc.
From: Rich Salz
Date: Monday, August 30, 2021 at 12:57 PM
To: "uta@ietf.org"
Subject: Planned 6125bis changes
I am planning on merging two pull requests next week, unless there is
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Using TLS in Applications WG of the IETF.
Title : Representation and Verification of Domain-Based
Application Service Identity within Internet Public Key Infrastruc
