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

[Tobias Gondrom <[e-mail]>]

 Ok, let's try to resolve this.
Over the last three days I've been working on possible changes to the
current draft that offer a way to store dssc in it. And I think I found
options that could be done fairly straight forward, but will need to
discuss the best options/wording with Aljosa tomorrow.
And I think we can add something to the security considerations, too.

Regarding Denis point #3: you mentioned that beyond the additional
discussion in the security considerations you feel further changes to
the main body would be necessary. Could you please elaborate, why, what
you mean by that / what you think is missing or a problem?

Tobias



On 10/19/2010 06:29 PM, Denis Pinkas wrote:
> Responses are in-line.
>  
>
>     ----- Message reçu -----
>     *De :* ltans-bounces <mailto%20:[e-mail]>
>     *À :* ltans <mailto%20:[e-mail]>
>     *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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/ltans
>
>
> _______________________________________________
> ltans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ltans