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