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

["Andreas Menke" <[e-mail]>]

Hello to all,

 

your discussion seems to me a bit misleading. In case I want to verify an
ERS I do it in my security context. We do NOT have a signing process like
AdES where we want to keep context information for use in future time as
part of the signer role; we DO have a time-stamping process and we DO
time-stamp for keeping cryptography at top of security. Nothing more.
Everything else is part of private data which has to be kept in the data
section.

 

The hard decision comes from the my fear of many different policies and many
different archives which could not interact (e.g. migration) because any
policy and / or DSSC and so on is not understood by any archive system. And
that is worst case if a future archive cannot verify ERS without breaking
standard.

 

Kind Regards

 

Andreas Menke

 

-----------------------------
Andreas Menke
Team Leader, Development
Abteilungsleiter SecDocs

 

OpenLimit SignCubes GmbH

Saarbrücker Str. 38a

D - 10405 Berlin

 

Tel:    [phone]

Fax:    [phone]

Mobil: [phone]

 

E-Mail:   <mailto:[e-mail]>
[e-mail]

Web:      <http://www.openlimit.com/> http://www.openlimit.com/

 

Geschäftsführer: 

Marc Gurov, Armin Lunkeit,

Nadine Model (Prokuristin),

Dr. Stephan Lachmann (Prokurist)

Sitz der Gesellschaft: Berlin

Amtsgericht Charlottenburg HRB 86352 B

Finanzamt für Körperschaften II

St.-Nr. 37/155/20819

USt-ID: DE 224136339

 

OpenLimit unterstützt den Wettbewerb "Digitale Identität 2020", bei dem
junge Menschen das digitale Leben in 10 Jahren beschreiben und tolle Preise
gewinnen können. Bitte weitersagen!

 <http://www.facebook.com/note.php?note_id=388251447004>
http://www.facebook.com/note.php?note_id=388251447004 

 

Von: [e-mail] [mailto:[e-mail]] Im Auftrag von
Denis Pinkas
Gesendet: Dienstag, 19. Oktober 2010 19:29
An: ltans
Betreff: Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-07.txt

 

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] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/ltans