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

["Denis Pinkas"<[e-mail]>]

Responses are in-line.

----- Message reçu ----- 
De : ltans-bounces 
À : ltans 
Date : 2010-10-18, 20:49:37
Sujet : Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt


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.
I understand the first sentence, but not clearly the second one.
> 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 AES (Advanced Electronic Signature) does support that case. 
However, it does not mandate to support it, since the risk of a CRL Issuer compromise 
is much lower than the risk of the signer's key compromise.
A second time stamp token can be placed on the references of the certification path 
including the revocation information. Since the references include a hash of the values, 
there is a full protection. For example, see  XAdES-X type 2. 
 > 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.

Fine.

> 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.

Indeed, ERS does not support these features.

Aljosa
_______________________________________________
ltans mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ltans