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

Stephen Kent <kent@bbn.com> Mon, 14 March 2011 15:40 UTC

Return-Path: <kent@bbn.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F357E3A6D1C; Mon, 14 Mar 2011 08:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.504
X-Spam-Level:
X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF+3tJOIUyCH; Mon, 14 Mar 2011 08:40:04 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 670023A6D2B; Mon, 14 Mar 2011 08:40:04 -0700 (PDT)
Received: from dhcp89-089-213.bbn.com ([128.89.89.213]:49160) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Pz9te-000MNL-9U; Mon, 14 Mar 2011 11:41:26 -0400
Mime-Version: 1.0
Message-Id: <p06240802c99ff4ab2d41@[10.84.130.113]>
In-Reply-To: <201103110458.p2B4wgaa024318@fs4113.wdf.sap.corp>
References: <201103110458.p2B4wgaa024318@fs4113.wdf.sap.corp>
Date: Mon, 14 Mar 2011 11:41:19 -0400
To: mrex@sap.com
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: draft-ietf-sidr-res-certs@tools.ietf.org, 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.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 14 Mar 2011 15:40:07 -0000

At 5:58 AM +0100 3/11/11, Martin Rex wrote:
>Stephen Kent wrote:
>>
>>  n to act as CAs , and we want to limit their liability.
>>  One way to do this is to restrict the fields and extensions in
>>  resource certs to make then not very useful for other applications.
>
>A CA should never sign extensions that it doesn't understand.
>Why has the RP to be bothered with this?

this is not about signing certs with extensions submitted by a 
Subject and which the CA does not understand.

>A request "everything must be considered critical, even if not marked
>as such" implies that every conceivable extension can only be a constraint.

I would prefer to say that the vast majority of extensions are 
excluded from this profile, to make it easier for RP software to 
process resource certs. The critical marking is not equivalent to 
what we have stated in this doc, although there are similarities. For 
example, there are a lot of standard extensions that 5280 requires RP 
software to recognize that are explicitly forbidden in the RPKI 
context.

>With its original meaning, the "ciriticality" flag could be used to sort
>extensions into "constraints" (critical) and "capabilities" (non-critical).

Note that not all extensions can be marked critical, so that using 
the critical flag would not be a solution in all cases anyway.

>The problem with newly inventend constraints is that they require flag days.
>capabilities do not suffer from this, and allow for a smoother migration.

This doc is a profile of 5280 and thus the imposition of constraints 
is to be expected. I do not know what you mean by the phrase "... 
capabilities do not suffer from this ..."

>  > I also note that we want to impose these constraints on both CAs and
>  > RPs, because we have lots of examples of CAs issuing "bad" certs,
>>  accidentally. se want to use RP strictness to help "motivate" CAs to
>>  do the right thing :-).
>
>I don't think that this idea will work.
>The consumers of the technology will want things to interoperate,
>not to fail.  And implementations will provide the necessary workarouds.

Interoperability is NOT enhanced by allowing certs with extensions 
that are extraneous to the focus of this architecture, and to the CP 
for this PKI. I suggest you read the architecture doc and the CP, 
both of which are available at the SIDR page to get a better sense of 
the context targeted by this profile.

>Besides, such an idea is in conflict with rfc-2119 section 6
>
>6. Guidance in the use of these Imperatives
>
>    ... they must not be used to try to impose a particular method
>    on implementors where the method is not required for interoperability.
>

I disagree with our reading of this text, relative to this context.

Steve