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

Stephen Kent <kent@bbn.com> Tue, 01 November 2011 10:13 UTC

Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E280F21F8F56 for <sidr@ietfa.amsl.com>; Tue, 1 Nov 2011 03:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.892
X-Spam-Level:
X-Spam-Status: No, score=-105.892 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUar8RvNgLKg for <sidr@ietfa.amsl.com>; Tue, 1 Nov 2011 03:13:19 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3788521F8F53 for <sidr@ietf.org>; Tue, 1 Nov 2011 03:13:19 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:41761 helo=[193.0.26.186]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1RLBKe-00089x-UC; Tue, 01 Nov 2011 06:12:37 -0400
Mime-Version: 1.0
Message-Id: <p06240801cad455872b85@[193.0.26.186]>
In-Reply-To: <CAD4D250.1C3C5%terry.manderson@icann.org>
References: <CAD4D250.1C3C5%terry.manderson@icann.org>
Date: Mon, 31 Oct 2011 09:59:22 -0400
To: Terry Manderson <terry.manderson@icann.org>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: "draft-ietf-sidr-algorithm-agility@tools.ietf.org" <draft-ietf-sidr-algorithm-agility@tools.ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-algorithm-agility-03
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2011 10:13:20 -0000

At 5:31 AM -0700 10/31/11, Terry Manderson wrote:
>On 31/10/11 8:57 PM, "Stephen Kent" <kent@bbn.com> wrote:
>
>>  At 7:18 PM -0700 10/30/11, Terry Manderson wrote:
>>
>>  We have included dates for alg start an EOL because they affect all
>>  RPs, and we want to make life predictable for RPs. Also, because the
>>  WG agreed that alg transition will be top-down (to avoid geometric
>>  growth in the repository system), it is necessary to set alg
>>  transition dates, for the benefit of
>>  CAs as well.
>>
>
>I understand why you want to, but don't come to the same conclusion as to
>the mechanism.
>
>Is that really the IETF's job?

SIDR was tasked by the SEc ADs to develop an alg transition architecture.
The authors believe that uniform milestones are necessary as part of 
a credible plan.

>Is there prior art in the IETF where this has been done in such a date
>specific manner?

Not sure.

>  >> [1] I would think that as soon at the document is updated and 
>published they
>>>  are able to be used.
>>
>>  The top tier CAs have to be ready to issue certs under the new alg before
>>  any lower tier CAs can do so, so we need a set date, agreed upon, in
>>  the future,
>>  to start the transition.
>
>Call me a dirty rotten cynic but I just don't see this operational aspect of
>one or more running RPKI hierarchies as part of the IETF. Although you can
>prove me wrong, and I'll concede to an already enacted example where dates
>were set for some artifact.

We have to have two, parallel hierarchies to avoid a flag day. This 
is not a situation where every CA can decide, locally, when to 
transition, because the the alg change affect ALL RPs.

>  > We want to encourage RPs to verify their ability to use the new Suite, but
>  > we also realize that, during transition, there may be problems. So,
>>  we RECOMMEND use of Suite B, but require that if either Suite works,
>>  the RP MUST accept the data as valid. That provides a fall back
>>  position in case a CA doesn't get it right.
>>
>
>In which case some clarification to the text could go a long way. I suspect
>in the effort to simplify a complex process the text became too brief.

OK.

>  >> issuance of suite C products MUST be considered invalid.
>>
>>  we can revisit this text to try to make it clearer, if others agree with
>>  your observation.
>>
>>>   Section 5.
>>>
>>>  I think some discussion of the dates, and for communicating 
>>>twilight and EOL
>>>  dates between the parent and the child should be here. I don't quite hold
>>>  the belief that it's a unidirectional downward assertion from parent to
>>>  child. In may well be in PKI - there there is a raft of operational
>>>  interaction  that surrounds that.
>>
>>  The dates for alg transition are published and accessible to
>>  everyone, so there is no need for pairwise communication of the
>>  dates. Because the alg transition affects ALL RPs, not just the
>>  children of a given CA, it is important to mandate the transitions on
>>  a global basis.
>>
>
>I'm still not with you on this - I understand that it makes life easy to say
>"the IETF said 12/12/2018 is D-Day, get with it" .. ... buuuutt I see that
>as a step beyond what the IETF should do.

If not the IETF, then whom? The IETF (via SIDR) is the author of the 
CP. This is an extension of the CP, in many respects.

>  >> Section 6.
>>>
>>>  Can you spell out what you technically mean by "keep any relationship
>>>  between " in para 1?
>>
>>  We will revise this sentence. The text is intended to note that the
>>  data extracted from the repository, signed under each alg, are
>>  treated separately. Thus one gets a compete, valid chain of data via
>>  Suite A or Suite B, but not a mix of data under A and B. The next
>>  paragraph explains this.
>
>right, there is a discontinuous leap there that I didn't get. Clarification
>would be appreciated.

OK.

>  >> Section 7.
>  >>
>>>  Can you expand the recommendation in keeping the parallel certificate
>  >> hierarchies in sync by also identifying the Alg A/Alg C mix? (phase 4)
>>
>>  In phase 4, Suite C products MAY be present, which means that they
>>  also may be absent. So, we cannot say that the hierarchies are
>>  parallel any more.
>
>So perhaps suggest to the RP/Child CA that in the situation where a
>revocation is issued for Suite A, _if_ there are products with matching
>information for the Suite A revocation, a Suite C revocation should also be
>issued.

If my coauthors agree, I think this could be added,


Steve