[woes] Scope of this work

"Jim Schaad" <ietf@augustcellars.com> Fri, 02 September 2011 19:27 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: woes@ietfa.amsl.com
Delivered-To: woes@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8221F8CFC for <woes@ietfa.amsl.com>; Fri, 2 Sep 2011 12:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.441
X-Spam-Level:
X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, 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 cJ9LCtbMuYNT for <woes@ietfa.amsl.com>; Fri, 2 Sep 2011 12:27:58 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 139AD21F8CFB for <woes@ietf.org>; Fri, 2 Sep 2011 12:27:57 -0700 (PDT)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 09A222CA5B for <woes@ietf.org>; Fri, 2 Sep 2011 12:29:33 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: <woes@ietf.org>
Date: Fri, 2 Sep 2011 13:05:50 -0700
Message-ID: <054301cc69ab$b65cf050$2316d0f0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AcxpqjvJZKZL6saGRaWhT8ciiGrtiA==
Subject: [woes] Scope of this work
X-BeenThere: woes@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Web Object Encryption and Signing \(woes\) BOF discussion list" <woes.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/woes>, <mailto:woes-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/woes>
List-Post: <mailto:woes@ietf.org>
List-Help: <mailto:woes-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/woes>, <mailto:woes-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Sep 2011 19:27:58 -0000

I am still trying to get my head on the things that people do and do not
think are going to be needed for this work.  Specifically I am trying to
figure out what are the set of features that people want to see.

I think that it would be useful if someone were to write a throw away draft
that did the following.

Taking the current CMS structures that we thing should be mapped -
AuthenticatedEnvelopedData, SignedData and AuthenicatedData.
Walk through each of the fields in these structures and write a one line
summary of the function of the field.
Make a statement that this is or is not a feature that should be followed in
the WOES work.

Examples:

SignedData.digestAlgorithms - provides a list of content digest algorithms
to allow for one pass processing.  WOES does not need one pass processing

SignedData.signerInfos - provides a list of different signers for the data.
WOES does not need to support multiple signers

SignedData.encapContentInfo.eContent - optional field allowing the signed
content to either be embedded in the structure or detached from the
structure.  WOES will not support detached content.

We can then determine which of the features are to be supported and are not
to be supported.  There may be other fields from different structures that
also needed to be looked at.  However I believe that it is universally
stated that we don't want to do the transforms of XMLDigsig, although it
might be that canonicalization may need to be looked at.

Note - arguments that could be added to the above would be:

The digestAlgorithms field provides for the ability for one pass processing
for both senders and recipients.  Given that senders only do things once and
recipients do things multiple times it might be useful to enable one pass
processing for recipients and state that it does not exist for senders.
Doing this does not mean that we need to have this field, it could instead
be supported by placing the data contained in the signerInfo field before
the encapsulated content.  Options would be No One Pass Processing, One Pass
Processing for both, One Pass Processing for Sender, One Pass Processing for
Recipient.

Jim