Re: [secdir] Secdir review of draft-ietf-sidr-res-certs

Sam Hartman <hartmans-ietf@mit.edu> Mon, 25 April 2011 16:02 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: secdir@ietfc.amsl.com
Delivered-To: secdir@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D9B8E075C; Mon, 25 Apr 2011 09:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.698
X-Spam-Level:
X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnCdoMwH5Jxp; Mon, 25 Apr 2011 09:02:53 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfc.amsl.com (Postfix) with ESMTP id 7F60EE0665; Mon, 25 Apr 2011 09:02:53 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7480920378; Mon, 25 Apr 2011 11:59:15 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E821C4543; Mon, 25 Apr 2011 12:02:40 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Stephen Kent <kent@bbn.com>
References: <tslhbbag9m1.fsf@mit.edu> <4D791B26.8020001@vpnc.org> <tsl4o7ag5fw.fsf@mit.edu> <4D79271E.6080707@vpnc.org> <tslzkp2elyf.fsf@mit.edu> <p06240801c9ce424e70b1@[128.89.89.62]>
Date: Mon, 25 Apr 2011 12:02:40 -0400
In-Reply-To: <p06240801c9ce424e70b1@[128.89.89.62]> (Stephen Kent's message of "Fri\, 15 Apr 2011 14\:45\:46 -0400")
Message-ID: <tsl62q2tj33.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: draft-ietf-sidr-res-certs@tools.ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Apr 2011 16:02:54 -0000

Steve, thanks for your note.
I realize the certificate resource profile document has been approved,
but I'd still like to understand what is happening here.


I'm having trouble reconciling the new text  you've added to the
document with draft-ietf-sidr-signed-object.

        2- During phase 2 CAs MUST issue certificates under the new profile,
and these certificates MUST co-exist with certificates issued under the old
format. (CAs will continue to issue certificates under the old OID/format as
well.) The old and new certificates MUST be identical, except for the policy
OID and any new extensions, encodings, etc. Relying parties MAY make use of the
old or the new certificate formats when processing signed objects retrieved
from the RPKI repository system. During this phase, a relying party that elects
to process both formats will acquire the same values for all certificate fields
that overlap between the old and new formats. Thus if either certificate format
is verifiable, the relying party accepts the data from that certificate. This
allows CAs to issue certificates under


However, when I look at section 2.1.4 in the signed-object document ,
the signer can only include one certificate.
How does that work during phase 2 when some of the RPs support the new
format and some only support the old format?
Your text above suggests that RPs grab the certificates from the RPKI
repository, but it seems at least for end entity certificates they are
included in the signed object.
What happens for end entity certificates during this form of upgrade?