Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt

"Aljosa Jerman Blazic" <aljosa@setcce.si> Mon, 18 October 2010 18:47 UTC

Return-Path: <aljosa@setcce.si>
X-Original-To: ltans@core3.amsl.com
Delivered-To: ltans@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B78A3A6BB0 for <ltans@core3.amsl.com>; Mon, 18 Oct 2010 11:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.296
X-Spam-Level:
X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=1.303, BAYES_00=-2.599]
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 D1QkCv8VxrZI for <ltans@core3.amsl.com>; Mon, 18 Oct 2010 11:47:58 -0700 (PDT)
Received: from setcce.si (mail.setcce.si [88.200.65.130]) by core3.amsl.com (Postfix) with ESMTP id 42D6D3A6E34 for <ltans@ietf.org>; Mon, 18 Oct 2010 11:47:53 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 18 Oct 2010 20:49:37 +0200
Message-ID: <B365DBD652563B41A90F1F3B546A6C8FB95407@localpolitix.setcce.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt
thread-index: ActuuWtloMnE2kxdSfSFnBdY0M2WCAAOfvfA
References: <FAD1CF17F2A45B43ADE04E140BA83D4801189964@scygexch1.cygnacom.com> <DreamMail__134022_99246688488@msga-001.frcl.bull.fr>
From: "Aljosa Jerman Blazic" <aljosa@setcce.si>
To: "ltans" <ltans@ietf.org>
Subject: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt
X-BeenThere: ltans@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: LTANS Working Group <ltans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ltans>, <mailto:ltans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ltans>
List-Post: <mailto:ltans@ietf.org>
List-Help: <mailto:ltans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ltans>, <mailto:ltans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Oct 2010 18:47:59 -0000

Denis,

My comments in-line

 
> Carl,
> 
> 1 - You said:
> 
> [Carl] DSSC applies at validation time.  I agree with Tobias that
while
> one could package the policy with a data item it is not necessary.  It
> doesn't really matter what policy the LTA had in mind.
> What matters is that the evidence record passes the policy used by the
> relying party.
> I see no reason to make a change to include DSSC policy in the XMLERS
> format.
> 
> Let us make a comparison with the concept of signature policy.
> Electronic sigantures comes with two flavors: BES (Basic ES) and EPES
> (Explicit Policy ES).
> 
> In EPES, the signature policy is indicated. My request is to be able
to
> incorporate the maintenance policy, like in EPES.
> You say you don't need it, like in BES. So let us make it OPTIONAL,
> which means that it will be possible to place it in the structure,
> whereas it is not the case today.

We can evaluate this option and see if it fits as my concern is to what
extent optional parameters are to be added. In case of maintenance
policy I would at least miss the original operation policy. With this
info one could decide on the reliability of ERS evidences and ERS
operation.

> 2 - You said:
> 
> [Carl] I disagree, for reasons you have cited in the past.  There will
> always be a grace period applied at validation time so this "MUST be
> proven at the time the new TST is applied" cannot be true.  In any
> case, these sorts of issues are for the relying party to appraise and
> the policies used by relying parties may vary, hence DSSC need not be
> included.
> 
> When you consider a grace period, the TST on the previous data can be
> applied first and the CRL for the previous TST captured, e.g. 24 hours
> later.

Now what happens if the CRL is compromised or ceases to exist, so its
integrity is questionable? The information (CRL) provided after TST does
not give any value at all only if it is ERSed as the rest of the
information. Similarly, the AES does not consider such approach.
 
> The DSCC information used at that time should also be added to the
> structure, before the new TST is applied.
> 
> In this way, it will be possible to split the overall verification by
> doing two sequences of verifications in any order:
> a) verifying the whole structure, making the assumption that every
DSCC
> information that has been used is correct, and
> b) verifying that every DSCC information placed in the structure comes
> from a reliable source and was correct
>     at the time indicated in the associated TST.
> 
> The advantage is that check a) can be fully automated.

Agree if the reason for DSSC inclusion stands.

> 3 - You said:
> 
> [Carl] A security consideration on this topic seems like a reasonable
> thing to do.  Tobias, can you add a security consideration to address
> the separation of evidence record from policy?  I think that will
close
> this issue.
> 
> Addressing the issue in the security considerations is fine. However,
> changes in the main body of the document are still necessary.

As said before, optional element might be considered, however in this
case, I would say, the question remains open with the original ERS
syntax (I think you have mentioned that already). Security
considerations can be updated to address the above issues.

Aljosa