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

Brian Dickson <> Tue, 08 November 2011 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6999721F8B29 for <>; Tue, 8 Nov 2011 04:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.278
X-Spam-Status: No, score=-3.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g51nVYOFqMKG for <>; Tue, 8 Nov 2011 04:48:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E662521F8B39 for <>; Tue, 8 Nov 2011 04:48:18 -0800 (PST)
Received: by faas12 with SMTP id s12so579190faa.31 for <>; Tue, 08 Nov 2011 04:48:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vcqSfABbNjB2HFkhnCKsCDcDLJPvnkOsKj8V7HrztAY=; b=lRfPH8+DaBTnQ9a/VCtC/gKjDxNX8A7jc+H39gqIgaDO8bYfJ9q2+GA935gbK52fj0 HchQNXmKKLYRNXG7Fwlk2GOrRuEIFfruAcj0pQGVPzaWCV+a0JUzDBmsgV2i7xFmqmXS fzjLpzmJiNALHdgKmkmDZyWRuMYV+TUtVdJ50=
MIME-Version: 1.0
Received: by with SMTP id e8mr16150742fah.27.1320756498025; Tue, 08 Nov 2011 04:48:18 -0800 (PST)
Received: by with HTTP; Tue, 8 Nov 2011 04:48:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 08 Nov 2011 07:48:17 -0500
Message-ID: <>
From: Brian Dickson <>
To: Roque Gagliano <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "Murphy, Sandra" <>, "" <>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Nov 2011 12:48:22 -0000

On Tue, Nov 8, 2011 at 5:40 AM, Roque Gagliano <> wrote:
> Hi Brian,
> Thanks for your comments.
> Please see inline.
> Roque
> (snif)
> So the analogous high-level design for agility SHOULD be as follows:
> - new CP documents may be published, with new OIDs
> The CP document in section 6.1.5 refers the definition of the Algorithm
> Suite to the draft-ietf-sidr-rpki-algs document. There are not OID defined
> in the CP document. That is why in our document we refer to an update of
> this document instead.

I was actually referring to the OID _of_ the CP document itself,
in section 1.2.

And in draft-ietf-sidr-res-certs-22, section 9, use of that OID is
referenced, including
how the change of OID gets handled.

The change-of-OID process identified there would be necessary, even if
the res-certs
format did not change, so long as there was some other reason for the
OID change.

And in draft-ietf-sidr-cp-17, section 9.12.3 describes when the OID must change.
Clearly, changing the algorithm RFC used by the CP, would require a new CP with
a new OID, since it directly affects acceptability of RPKI certificates.

> - ONLY when a CA with a given CPS decides to change CP does that CA
> need to execute a locally-significant key+alg roll
> - The CA would issue new certs with the new CP which itself lists
> additional algorithms
> - The same procedure would be executed in multiple phases - issue new
> child certs published under the old main cert; move them to the new
> cert, rewriting/overwriting in the same location
> In section 4.1 we defined:
>    CA Ready Algorithm B Date  - After this date, all (non-leaf) CAs MUST
>                be ready to process a request from a child CA to issue a
>                certificate under the Algorithm B suite

What I am saying is, there is no reason to require a change to a child's CPS,
and thus its CP, and thus its algorithm suite, simply because the parent CA
is making this change. The whole 'all (non-leaf)' stuff is un-necessary.

Each CA may operate its CPS independently. Algorithms are explicitly included
via OIDs in every cert. A child CA may need to sign with algorithms accepted by
the parent CA, but they can issue certs with a different CP, signed according
to the algorithms _of_that_CP_ (their own CP, independent of the choice of
CP used by the parent CA).

The choice of algorithm acceptability for a given cert, comes from the CP.
It needs internal consistency. There is no further requirement on
algorithm choice.

> If I summarize your comment, you are stating that the definition of "ready"
> for a CA should also include an update on its CPS to refer to the new suite.
> This was understood but as what each CA will need to do to be ready to
> process requests from a child CA is local to that CA, we did not got into
> the details.

Okay, yes, that was the bit I said was technically correct...

> The process that you have described is indeed the proposed algorithm in the
> document for the CAs, where we adopted a "top-down" process and we maintain
> the two suites independent. The document also includes the transition to the
> new suite on the RPs that are distributed globally.

That's the part I disagree with entirely - there is no "top-down"
required at all.
There is no "globally". There is only the requirement operationally
that any newly
published CP with new OID be supported by RPs.

The publishing the new CP with new OIDs with sufficient time for RPs
to implement
those changes is the only timeline issue. It is a "sunrise" issue - a
minimum time
after publication before ANY CA begins to issue certs using the new OID.

After that date, any CA may choose to use the new CP, without
requiring any change
to either the CA's parent, or the CA's children, except as relates to
the algorithms
used on new certs, which the child needs to discover. This has no bearing on the
CP _used_ by the child CA in issuing certs to grand-child CAs - that
is under the
local policy of the child CA.

Every CA is free to choose the CP it uses from among the published CPs, modulo
the issue date plus delay required (6 months in the initial CP document).

Issuing a second (or third, or fourth) CP does _not_require_ANY_ CA to change
algorithm suite.

Perhaps a separate BCP can recommend, or even require, use of some subset
of CP documents, or at some point an old CP could be moved to historic or
depracated status.

However, that should _not_ be part of the alg-agility document.
Agility should limit
itself to the mechanism by which a _single_ CA changes algorithm
suite, including
the possibility that the new suite still include all the algorithm(s)
from the previous
suite, the possibility that multiple algorithms are part of the new
suite, as well as
case of (but not a requirement that) _an_ older algorithm is dropped
from the suite.

> Regards,
> Roque