Re: [jose] Comments on draft-barnes-jose-spi-00

Richard Barnes <rlb@ipv.sx> Tue, 02 April 2013 18:57 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EBB21F8C71 for <jose@ietfa.amsl.com>; Tue, 2 Apr 2013 11:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 F1k+IbNnC55j for <jose@ietfa.amsl.com>; Tue, 2 Apr 2013 11:57:50 -0700 (PDT)
Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 183D121F8B9F for <jose@ietf.org>; Tue, 2 Apr 2013 11:57:50 -0700 (PDT)
Received: by mail-oa0-f49.google.com with SMTP id j6so708533oag.8 for <jose@ietf.org>; Tue, 02 Apr 2013 11:57:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Y86fRPoET/JCHoeFoNVYU0elnW8w6jCiFGVyzXNhtvs=; b=LBT/onXw9gDAleuIHffqe6kVpszZOXGZ7PT4Qe43BNI4X0hcXHSuf8030g/UrKq/R1 gN/LG92NzTng9J+YgSKK6jSzGIN6SeCrptg5YlExvkhImBb2dUKDBNfcUnb3D19THkwE 0hDlt2nQ2L/+pnlGyGop7hKQYZKn//1dxLZDYlCHrzoei3A6p21H2O6o5miI/9IdcIIW lHxGWkLz/LoVNblS06ggsUiVXHAr2d+5A+PtbAabiCE0uF8IDxJWkVJAT83jRVOn9aUk pgzddSqhoLoX0NB+XEuzyaJQ+INFnsp6wP/kVa+wjczDikuIC172kurYRrhBihjBFPpp 6HQw==
MIME-Version: 1.0
X-Received: by 10.182.39.69 with SMTP id n5mr6181424obk.72.1364929069227; Tue, 02 Apr 2013 11:57:49 -0700 (PDT)
Received: by 10.60.160.201 with HTTP; Tue, 2 Apr 2013 11:57:49 -0700 (PDT)
X-Originating-IP: [192.1.51.16]
In-Reply-To: <515B2909.901@gmx.net>
References: <005301ce2fba$e4c68100$ae538300$@augustcellars.com> <515B1862.2020204@gmx.net> <CAL02cgSLFeh_wzaC0nb7=Xg74_3S2irg9bHxA6cvPF3vbwvTRw@mail.gmail.com> <515B215B.1000104@gmx.net> <CAL02cgT0kRH+4Uz+mTht47r3k-wEJ02cj=RoK8WTZEhOnfkiKA@mail.gmail.com> <515B2909.901@gmx.net>
Date: Tue, 02 Apr 2013 14:57:49 -0400
Message-ID: <CAL02cgRjkUbU3UNkqouMHUJyGDMUiW9f6Lt0qGb6YLs=EfAnJQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: multipart/alternative; boundary="f46d0447975551020904d96550e3"
X-Gm-Message-State: ALoCoQn9QRWz4lfIIeRL3XtxnbT2olyChkXArHMcKOFLaslkvIn+CcYMhHhZIBKbf8Rd8F99QE5P
Cc: Jim Schaad <ietf@augustcellars.com>, jose@ietf.org, draft-barnes-jose-spi@tools.ietf.org
Subject: Re: [jose] Comments on draft-barnes-jose-spi-00
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 18:57:51 -0000

On Tue, Apr 2, 2013 at 2:52 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net
> wrote:

> On 04/02/2013 09:25 PM, Richard Barnes wrote:
>
>>
>> This is exactly my point.  These pre-negotiation cases prevent us from
>> having clear requirements levels.
>>
>> The goal of SPI is to explicitly say "SPI indicates that pre-negotiated
>> parameters are being used, so some things that are otherwise REQUIRED
>> might be missing."  That way, you can still have fields that MUST be
>> included in general, but if you include an SPI, you can omit them.
>>
>
> AHA. Now I got it.
>
> There are two options to address it:
>
> 1) Create a new parameter, as you suggested
>
> 2) Fix the specs
> (to allow parameters like alg to be optional)
>


Option 2 is not good, because it means that if you have an object that's
*not* pre-negotiated, you don't know what has to be there.  In fact, both
types of object (with and without pre-negotiation) benefit from Option 1,
since the stronger requirements could be applied in both cases.  In the
pre-negotiated case, you would just apply the requirements after
"rehydrating" the object.

--Richard