On Wed, Sep 08, 2021 at 04:45:24PM +0000, 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
>
> If the client does not find a presented identifier matching any of the
> reference identifiers then the client MUST
> proceed as described as follows.
>
> If the client is an automated application not directly controlled
> by a human user, then it SHOULD terminate the communication attempt with
> a bad certificate error and log the error appropriately.
> An automated application
> MAY provide a configuration setting that disables this behavior, but it
> MUST enable the behavior by default.
>
> If the client is an interactive client that is directly controlled by a human
> user, then it SHOULD inform the user of the identity mismatch and
> automatically
> terminate the communication attempt with a bad certificate error; this
> behavior
> is preferable because it prevents users from inadvertently bypassing security
> protections in hostile situations.
>
> Some interactive clients give advanced users the option
> of proceeding with acceptance despite the identity mismatch.
> Although this behavior can be appropriate in certain specialized
> circumstances, it needs to be handled with
> extreme caution, for example by first encouraging even an advanced user to
> terminate the communication attempt and, if the advanced user chooses to
> proceed anyway, by forcing the user to view the entire certification path
> before proceeding.
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
the pinned certificate.
Local policy that statically enforces a given certificate for a
given peer is best made available only as prior configuration,
rather than a just-in-time override for a failed connection.
Feel free to word smith if largely acceptable, or clarify objections if
not...
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
