Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03

[Brian Dickson <[e-mail]>]

On Sun, Nov 13, 2011 at 9:16 PM, Stephen Kent <[e-mail]> wrote:
> You suggested that we codify how the community should deal with problems
> that motivate delaying a phase transition. We're not writing the timeline
> document now, but the text at the beginning of this message is an effort to
> make sure such considerations are addressed in that document.

When you say "timeline document", do you mean "timeline for specific
implementation of the phases in this document"?

I ask because the algorithm-agility sure looks like a timeline document.

The main concerns rise from the content and order of the phases, and their
consequences.

> Phase 0 is the start of the process, when a new algorithm suite has been
> selected and the timeline published.
>
> Phase 1 requires all CAs to be able to issue certificates under Suite B.
>
> Phase 2 requires that CAs MUST publish all signed products under Suite B, as
> well as Suite A, and RP MAY be prepared to validate these products using
> Suite B.
>
> Phase 3 requires that RPs MUST be able to process Suite B signed products,
> and RPs are encouraged to validate signed products using Suite B.
>
> Phase 4 begins the phase out of Suite A.
>
>
> First, not that a CA cannot unilaterally decide to transition to a new
> algorithm. There is a requirement that the issuer of its certificate is
> prepared to accept a certificate request under the new algorithm suite
> (because of the PoP requirement).

This statement is entirely predicated on having Phase 2, as it is currently
defined, after Phase 1 (CAs ready for receiving B) and before Phase 3
(when RPs are able to validate using B). I don't see what this step
in this order, buys us, or even that it is necessary at all.

Let's take a look at what happens after Phase 3:
- RPs speak "B".
- CAs can process "B".

Is this not the (only!) pre-condition required for supporting any of
the four combinations?

> If we allow CAs to "do their own thing," there is the potential for
> four combinations:
> - a Suite A certificate issued under Suite A
> - a Suite A certificate issued under Suite B
> - a Suite B certificate issued under Suite A
> - a Suite B certificate issued under Suite B
>
> The exponential growth arises if we have Suite A and B product sets at each
> tier.

I don't see the requirement to support more than one certificate
(ie of more than one of the four types.)

After Phase 1 and Phase 3, but ignoring your Phase 2, we know:
- RPs speak "B"
- CAs can accept requests with PoP == "B".

A certificate of any of the four types can be issued by any CA, and
validated by any RP.
Which type depends only on the CA (signature alg) and the subordinate
CA (key/PoP type).

There is no exponential growth _unless_ multiple cert types for each
cert are maintained,
which I disagree with as being a requirement _at_all_. I do not see a
reason to need
more than one certificate, regardless of which of the four types it is.

So, the only possible danger with allowing any CA to switch to "B"
whenever it wants,
is that should that occur before the end of phase 3 (when all RPs speak "B"),
all subordinate certificates will be at risk for not validating with
those RPs who are not
"B"-ready.

However, experimentation during the early deployment stages, almost demands for
this ability, and that there would be the expectation of such failure
by those using
(or more accurately, testing) code prior to widespread adoption.
Earliest work would
be done using leaf "B" certs, and early-deployment code. Gradually
additional levels
of testing (B-B and B-B-B), until enough traction in deployment in CA
code and RP code
has occurred. This eventually culminate with "B" root transition.

Deploying code without this incremental testing, and then expecting it
to "just work",
suggests a lack of experience and familiarity with the deployment of
new operational
code features in a multi-vendor environment on the Internet...

_Especially_ if there is no compelling reason. Can you show me what compels
the maintenance of both types of certificates, and a "fall-back-to-A" logic?

We have another term for "fall-back-to-foo" - it's called a "downgrade attack".

I'll withdraw my objection if anyone can make a truly compelling case using only
the assumptions above - Phase 1 and Phase 3, followed by widespread issuance
of production "B" certs, on a timeline entirely determined by local CA
decisions.

Brian