Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt
Stephen Kent <kent@bbn.com> Wed, 03 August 2011 18:06 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 5A5E621F8828 for <sidr@ietfa.amsl.com>; Wed, 3 Aug 2011 11:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.619
X-Spam-Level:
X-Spam-Status: No, score=-106.619 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnekSIznDqug for <sidr@ietfa.amsl.com>; Wed, 3 Aug 2011 11:06:15 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8E54321F881C for <sidr@ietf.org>; Wed, 3 Aug 2011 11:06:15 -0700 (PDT)
Received: from dhcp89-089-043.bbn.com ([128.89.89.43]:49200) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1QofMN-000LVP-SI; Wed, 03 Aug 2011 13:35:59 -0400
Mime-Version: 1.0
Message-Id: <p06240804ca5f343b9a28@[128.89.89.43]>
In-Reply-To: <Pine.WNT.4.64.1108021731050.8260@SMURPHY-LT.columbia.ads.sparta.com>
References: <20110802092022.13671.96567.idtracker@ietfa.amsl.com> <1C1A5E2A-1C8A-4023-B2BA-A2D340470649@cisco.com> <Pine.WNT.4.64.1108021731050.8260@SMURPHY-LT.columbia.ads.sparta.com>
Date: Wed, 03 Aug 2011 13:34:54 -0400
To: Sandra Murphy <Sandra.Murphy@sparta.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-899729537==_ma============"
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-03.txt
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: Wed, 03 Aug 2011 18:06:16 -0000
At 6:16 PM -0400 8/2/11, Sandra Murphy wrote: >Speaking only as a regular ol' wg member: > >The draft does not say why the mixed certificate prohibition was >needed in the first place. > >The new text says: > > This exception to the mixed algorithm suite certificate > rule is allowed because an EE certificate that is not used to verify > repository objects does not interfere with the ability of RPs to > download and verify repository content. > >There's a hint there that mixed certificates for CAs signing CA >certs might cause a problem for RPs. Goeff noted a serious problem that could arise if we allow for mixed certs at the CA level, i.e., a potential exponential directory explosion. I noted this in the briefing I made in Prague. (See slide 3, bullet 3.) >I think it would be good to describe the problems RPs would see if >CAs could sign CA certs with a mix of algorithms. > >And it might be good to say why the mixed certificate case for some >EE certs was desirable. It's not clear why one would want mixed mode EE certs, for any EE cert used to verify a repository object. It would impose a burden on all RPs (they would have to be able to deal with two suites). In contrast, mixed mode certs for EE certs that are NOT used to validate repository objects do not impose a burden on ALL RPs. Only RPs that need to process these certs to extract and use he public key would need to be capable of dealing with the alg for the Subject public key. >YMMV. > >Also, the draft says: > > In the RPKI, a CA MUST > NOT sign a CA certificate carrying a subject key that corresponds to > an algorithm suite that differs from the one used to sign the > certificate. > >It used to say that > > In RPKI an algorithm > suite MUST NOT sign a certificate carrying a subject key that > corresponds to another algorithm suite. > >To me, the old text sounded like issuance of any mixed certificate >was prohibited. yes, and it was also not good English :-). It would at least have to say "In the RPKI an algorithm suite MUST NOT be used to sign a certificate carrying a subject key that contains a key that is used with another algorithm suite. >The new prohibition applies only to CAs issuing a CA cert and the new >exception applies only to EE certs that are not used to verify >repository objects. The new text sounds to me like it leaves open >the case of EE certs that *are* used to verify repository objects. That was not the intent. The cited text at the beginning of this message was intended to describe the context in which it's OK to have a mixed mode EE cert. We can try to make this limitation clearer. Steve
- [sidr] Fwd: New Version Notification for draft-ie… Roque Gagliano
- Re: [sidr] Fwd: New Version Notification for draf… Sandra Murphy
- Re: [sidr] Fwd: New Version Notification for draf… Roque Gagliano
- Re: [sidr] Fwd: New Version Notification for draf… Stephen Kent
- Re: [sidr] Fwd: New Version Notification for draf… Stephen Kent
- Re: [sidr] Fwd: New Version Notification for draf… Roque Gagliano
- Re: [sidr] Fwd: New Version Notification for draf… Randy Bush
- Re: [sidr] Fwd: New Version Notification for draf… Sean Turner
- Re: [sidr] Fwd: New Version Notification for draf… Sandra Murphy
- Re: [sidr] Fwd: New Version Notification for draf… Sean Turner
- Re: [sidr] Fwd: New Version Notification for draf… Randy Bush
- Re: [sidr] Fwd: New Version Notification for draf… Warren Kumari
- Re: [sidr] Fwd: New Version Notification for draf… Roque Gagliano
- Re: [sidr] Fwd: New Version Notification for draf… Sean Turner
- Re: [sidr] Fwd: New Version Notificationfor draft… t.petch