Subject: Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

From: "[email-masked]" <[email-masked]>
Date: Mon, 4 Apr 2022 19:57:27 +0000

Thanks for taking the time to read this.

The use case may not be limited to only PQ certificates, but it is the main motivation of this work. It may support the scenarios you've described, but that is really an off-label benefit and not the intended use.

Regarding policies- this extension could be useful in a number of protocols and potentially for various use cases, since it is really a tool to facilitate with certificate ownership assertion. Because of that, we may want to refrain from making too many normative statements about policy, because we anticipate that policy surrounding this extension may not be uniform, even for the single use case we specify.

- Alie

________________________________
From: Michael Richardson
Sent: Wednesday, March 30, 2022 8:19 AM
To: Alison Becker (GOV); [email-masked]
Subject: Re: [lamps] New drafts available - non-composite hybrid authentication, and binding certs

[email-masked] <aebecke=[email-masked]> wrote:
    > If the certs are from different CAs, it is possible they use different
    > practices to issue the certificates. The two certs are independently
    > valid on their own, so if the verifier likes them both - great, if the
    > verifier likes one and not the other, then it depends on if the
    > implementation can fall back to using one cert, and whether or not the
    > appropriate one is agreeable.

It seems to me that we need to be a bit more precise about the "likes them both"
part.

a) we need some words to describe the policies involved.  Why? Because it
   will need to go into requirements, and because people will have to speak
   as to what policy failed when it fails.

b) when it fails back to using one cert, we may need to communicate this fact
   to users and administrators.

Can we use this for two (or n) pre-quantum ("legacy") certificates?
Is this a general mechanism for hedging against expiration?
To avoid keeping ones eggs in one basket?
An advantage of doing that is that it excercises the code paths more
frequently.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Apr 2022 11:08:34 -0400

[email-masked] <[email-masked]> wrote:
    > The use case may not be limited to only PQ certificates, but it is the
    > main motivation of this work. It may support the scenarios you've
    > described, but that is really an off-label benefit and not the intended
    > use.

Yes, I understand, but if it provides an immediate ROI then it will get the
new code paths and new error situations tested sooner, and I think that has
value.

    > Regarding policies- this extension could be useful in a number of
    > protocols and potentially for various use cases, since it is really a
    > tool to facilitate with certificate ownership assertion. Because of
    > that, we may want to refrain from making too many normative statements
    > about policy, because we anticipate that policy surrounding this
    > extension may not be uniform, even for the single use case we specify.

If the policy is non-uniform, then that makes specifying the policies even
more important.

It's not enough to present a sad-face emoji to an end user, and give them
nothing useful communicate to/through their support mechanisms.