[08:14:14] --- tobias has joined
[08:14:38] * tobias has set the topic to: test
[08:14:56] * tobias has set the topic to: IETF conference
[08:15:02] <tobias> test
[08:53:08] --- crw-ietf has joined
[08:53:51] <crw-ietf> good morning, tobias.
[08:54:08] <tobias> good morning carl
[08:54:38] <crw-ietf> hopefully our scribe made it into town. the weather situation here was pretty bad yesterday.
[08:54:46] <tobias> already saw that you got up early and already posted tons of comments.. ;-)
[08:55:22] <crw-ietf> yeah. any idea on the tagging one?
[09:00:36] --- yhetheridge has joined
[09:00:48] <tobias> Hello Young, welcome
[09:01:11] <yhetheridge> Hello, Tobias. Thank you.
[09:04:54] <tobias> @Carl: not on the tagging at the moment, tried to discuss the issue with the one who did implementation work the last months...
[09:06:53] <crw-ietf> i'll pose the question during the session. perhaps someone knows of an encoding rule that supports this.
[09:07:41] <crw-ietf> For anyone who shows up in the room during the session, the slides can be downloaded from https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 in the Security Area section of the page
[09:31:29] --- crw-ietf has left
[09:47:16] --- chokhani has joined
[10:00:09] <tobias> Ok, meeting should start soon - do we have a scribe in the room or has the traffic been too bad?
[10:01:13] --- masinter has joined
[10:01:50] --- geoffbeier has joined
[10:02:01] <geoffbeier> i'm in
[10:02:16] <geoffbeier> i'll be the jabber scribe this morning
[10:02:40] <tobias> Hi, thanks a lot!
[10:02:52] <yhetheridge> Great! Geoff! Thanks!
[10:04:26] --- greg has joined
[10:04:33] <geoffbeier> I'm assuming everyone downloaded the slides and is following along
[10:04:48] <chokhani> Yes
[10:05:01] <greg> good morning from mexico
[10:05:02] <geoffbeier> "Post-Dallas" slide is currently up
[10:05:25] <tobias> Of course.
[10:05:36] <geoffbeier> Carl notes that these are the same bullets as "Post-Vancouver"
[10:05:37] <tobias> @Greg: good morning.
[10:05:41] <geoffbeier> Agenda slide is up
[10:06:00] <geoffbeier> Milestone review has been moved to the end
[10:06:10] --- jimsch1 has joined
[10:06:15] <geoffbeier> Tobias' ERS slide deck is up
[10:06:35] <geoffbeier> There's one person in the audience who's implemented an XML version of ERS
[10:06:56] <tobias> who?
[10:07:00] <geoffbeier> (Alexei)
[10:07:22] <chokhani> I never received responses to my comments on the ERS I-D
[10:07:23] <geoffbeier> He indicated that he sent his XML to Tobias at one point
[10:08:28] <geoffbeier> We're currently on the slide with implementations
[10:08:36] <geoffbeier> and we've dropped over to look at the spec
[10:08:51] <geoffbeier> carl's discussing what appeared to be an encoding error in the sample message
[10:09:01] <geoffbeier> ActiveTimeStamp sequence
[10:09:22] <tobias> @chokani: replies to your comments and others have been sent to the WG alias (on Feb-7)
[10:10:06] <geoffbeier> Russ wants to know how you talk about the ActiveTimeStamp sequence
[10:10:37] <geoffbeier> The consensus in the room seems to be that this was indeed an error in tthe interop trials.
[10:11:21] <geoffbeier> Discussing changes for version-06 (1/2)
[10:11:33] <tobias> that is possible. Unfortunately I received the message only oday, so that I couldn't check back with the developers (from Opentext and FHG) about the issue and their tests...
[10:12:07] <geoffbeier> Carl says please post back to the list when you do :)
[10:12:24] <greg> are we on ltans-0?
[10:12:30] <tobias> yes
[10:12:36] <greg> thnx
[10:12:38] <tobias> @g5reg: yes
[10:12:59] <geoffbeier> Carl is soliciting comments on current ERS
[10:13:24] <geoffbeier> Alexei says he has a general problem with encryption and preservation of encrypted data
[10:14:00] --- LOGGING STARTED
[10:14:06] --- geoffbeier has joined
[10:14:17] <geoffbeier> sorry... i was kicked off
[10:15:24] <geoffbeier> discussion is on accommodating non-3161 timestamps
[10:15:43] <geoffbeier> issue: no treatment of verifying these timestamps
[10:15:51] <geoffbeier> carl feels the spec should go into detail there
[10:16:18] <geoffbeier> end of ERS deck
[10:16:36] <geoffbeier> discussion of wheteher to go to WG last call will be deferred until milestone review
[10:17:25] <geoffbeier> There's a pause while Carl loads updated slides for LTAP from a thumb drive
[10:17:44] --- tobias has joined
[10:18:19] <tobias> I have been kicked out too :-(
[10:18:30] --- yhetheridge has joined
[10:18:43] --- masinter has joined
[10:18:49] <geoffbeier> He's going to put the updated slides on the website now while Alexei presents from his laptop.
[10:19:53] <geoffbeier> slides are on their way up here: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65
[10:20:17] <yhetheridge> What was the result of the non-3161 consistency changes requested by Young?
[10:20:49] <geoffbeier> proposed word changes for version 6 are in the slides
[10:21:13] --- chokhani has joined
[10:21:21] <yhetheridge> Great as long as the wording appears in -06
[10:21:22] <geoffbeier> we're now on the first LTANS slide
[10:21:30] <geoffbeier> "Preservation"
[10:21:51] <masinter> LTAP slides?
[10:21:59] <geoffbeier> yes. sorry.
[10:22:12] <geoffbeier> The diagram is on the screen
[10:22:33] <geoffbeier> Alexei: he divides the process into 5 layers shown
[10:24:04] <geoffbeier> Current draft considers everything behind TAS in the diagram as a trusted archive service
[10:24:21] <geoffbeier> (SVCP in the diagram should be SCVP)
[10:27:51] <geoffbeier> 2 roles for LTAP: interaction for complete service, interaction with a notary service
[10:27:51] <geoffbeier> issue that hasn't been well enough addressed: handling of data that we're preserving
[10:27:51] <geoffbeier> archive object diagram is onscreen
[10:27:51] <geoffbeier> My apologies... the server is not keeping up with my typing :-P
[10:27:51] <geoffbeier> Alexei notes that the complementary data is often required by law
[10:27:51] <geoffbeier> My typing appears to be going into a black hole
[10:27:57] --- jimsch1 has joined
[10:28:02] <geoffbeier> are folks online?
[10:28:07] <masinter> yes
[10:28:12] <geoffbeier> we appear to be back.
[10:28:14] <chokhani> yes i had to sign back on
[10:28:15] <yhetheridge> yes
[10:28:35] <tobias> oh yes
[10:28:50] <masinter> 'archive object diagram'? which slide#?
[10:28:58] <tobias> slide 3
[10:29:07] <masinter> thanks
[10:29:08] <tobias> in ltans-1
[10:30:55] --- geoffbeier has left: Replaced by new connection
[10:31:06] <masinter> does 'document' include mime type and other content- headers?
[10:31:10] --- greg has joined
[10:31:33] <greg> had to rejoin
[10:33:11] <tobias> @larry: I'd say so, of course they might also end up in the meta-data (the box below)
[10:33:14] <greg> any word whether or not xml will be included in the standard as an alternative to asn.1?
[10:33:35] --- crw-ietf has joined
[10:34:15] <crw-ietf> wireless here is flaky. sorry for the poor connectivity.
[10:34:25] <crw-ietf> new slides are uploaded
[10:34:34] <crw-ietf> we're on services and configuration slide
[10:34:36] <tobias> and one question for the round after at the end of Alexei's presentation: why is everything behind TAS considered "trusted"? From my interpretation "trusted" mean" that not even the owner of the data/documents can manipulate the system (like at a trusted timestamp services). The rest of the system is from my understanding only "trusted" in the sense that the owner of the documents relies on th fact that the data is not lost and the system performs according to specification - right?
[10:35:35] <crw-ietf> on the last slide. will ask tobias' question.
[10:37:12] <crw-ietf> everything behind the TAS is not considered trusted.
[10:37:23] <crw-ietf> (answering tobias' question)
[10:37:43] <tobias> thanks
[10:38:57] <crw-ietf> ltap is used to request ers. other services will be distributed.
[10:40:03] <crw-ietf> regarding the question regarding xml version of ers, this has been done and schema provided to tobias, but it hasn't appeared in a draft yet.
[10:40:13] <crw-ietf> aleksej feels there is not much work to be done here.
[10:40:41] --- geoffbeier has joined
[10:40:48] <greg> is there a due date for observations regarding how xml could be incorporated
[10:41:37] <tobias> @alexei: concerning XML: at the moment I would focus on completing the ERS for ASN.1 mapping to XML should be easy after ASN.1 is final and submitted to IESG
[10:41:43] <masinter> is the ARCHIVE request like a 'file upload'? A data record with some other request information? Is there a relationship to MIME that is intended but not explicit?
[10:42:49] --- geoffbeier has left
[10:42:54] <crw-ietf> aleksej: ltap does nothold only data. aim is to define the process by defining the information needed ot start the preservation process
[10:43:22] <crw-ietf> ltap enables clients to be in control of parameters associated with archived data
[10:43:34] <crw-ietf> there could be support for submitting data by simple upload.
[10:44:01] --- dcrocker has joined
[10:44:24] --- geoffbeier has joined
[10:44:43] <crw-ietf> spec may be augmented with a remark to address using a protocol (e.g., ftp or smtp) to support submission
[10:44:50] <crw-ietf> possibly using a default policy
[10:45:03] <crw-ietf> any other LTAP questions/comments?
[10:45:32] <tobias> no
[10:45:52] --- isaaclan has joined
[10:45:52] <masinter> archiving data without agreement on the meaning of the metadata leaves you open to attacks by changing the interpretation of the metadata
[10:46:15] <crw-ietf> aleksej was just making similar comments
[10:46:47] --- geoffbeier has left
[10:46:52] <crw-ietf> pausing to setup next set of slides
[10:47:20] <masinter> think of archiving as a very slow email system... email gets delivered after 10 years. But you want the same security, privacy, authenticity requirements as you want for email, they just have to last longer
[10:47:28] <tobias> usually the archiving person can provide besides the metadata the definition of te metadata (like values and schema definition)
[10:47:51] <masinter> for email to work, sender and receiver have to agree on things like what the MIME types of the bodies are and what those things mean
[10:48:29] <crw-ietf> proceeding to slide deck 5
[10:48:43] <yhetheridge> so you're speaking of policy encodings, too?
[10:49:02] <tobias> @larry: not exactly agree: the sender just needs to use a format that is common enough that he can rely on it will still be around 10years later...
[10:49:37] <masinter> the encoding of what the name of the format is needs to be a standard part of the protocol, just like content-type is a standard part of email
[10:51:45] <crw-ietf> we're now on the pki artifact retention deck
[10:51:51] <crw-ietf> "purpose" slide
[10:52:15] <greg> ltans-5?
[10:52:20] <crw-ietf> yes
[10:52:24] <tobias> no ltans-4
[10:52:30] <crw-ietf> Carl indicates that the first bullet is untrue
[10:52:39] <crw-ietf> ers has some statement but needs much more
[10:52:51] <crw-ietf> "Mechanics" slide
[10:53:01] <crw-ietf> question: are these drafts appropriate for this group?
[10:53:09] <crw-ietf> there's been very little discussion on the topic
[10:53:20] <crw-ietf> clearly they're necessary... is this the right group?
[10:53:37] <tobias> comment on first bullet: the data for verification should not be specified in ERS, because several mechnisms might be used: include in document/signature or store it separately....
[10:53:47] <crw-ietf> One thing that Russ always thinks about is CRL at the time of archive submission and CRL + one at each step of the path?
[10:53:53] <crw-ietf> CRL each side of the archive event
[10:54:43] <crw-ietf> Carl notes the appendix to this draft that offers some different extensions that help this.
[10:54:55] <tobias> the verification data might be dependent on local laws etc. so we SHOULD NOT specify the place where to store them.
[10:54:55] <crw-ietf> Helps to drop back to using X.509 cumulative CRL
[10:55:09] <crw-ietf> but clients have to know how to process them
[10:56:09] <crw-ietf> Carl notes that we do need to specify how to use them
[10:56:15] <crw-ietf> (@tobias)
[10:56:21] <greg> does the standard specify a specific version of CRLs or CRLs in general (i.e. CRLv1, CRLv2, delta CRLs, etc.)
[10:56:25] <crw-ietf> and offer some places from which they can be retrieved
[10:56:39] <crw-ietf> Carl notes that we shouldn't be silent on this
[10:56:44] <chokhani> if you use the extensions, it needs to be v2
[10:57:23] <yhetheridge> yes
[10:57:26] <tobias> @Carl: maybe s.th. for LTAP?
[10:57:52] <crw-ietf> Carl sees this as separate from LTAP
[10:58:02] <crw-ietf> you should be able to verify an evidence record without LTAP
[10:58:15] <tobias> true.
[10:58:43] <crw-ietf> Russ asks what's the way ahead
[10:58:58] <tobias> but how about the fact that verification may be dependent on local laws and not universal?
[10:59:06] <crw-ietf> Carl: the way ahead by these drafts is to adopt htis binding between the ER and the verification data
[11:00:18] <crw-ietf> Russ notes that 3280 says that if a cert is not on CRL N and N+1 comes out
[11:00:38] <crw-ietf> if the cert is both revoked and expired it will be on N+1 and not N+2
[11:00:53] <crw-ietf> if we're going against that, this needs to go to a different WG
[11:01:09] <chokhani> but historical CRL with the X.509 extension can violate that rule
[11:01:19] <crw-ietf> Q from audience: Where does the requirement of CRL < nextUpdate time come from
[11:01:28] <crw-ietf> A: That's general client practice
[11:02:02] <tobias> instead of CRL OCSP could also be used?
[11:02:13] <chokhani> If you did not use < nextUpdate, you will not be able to limit the CRL replay attack time window
[11:03:04] <crw-ietf> @tobias: OCSP has the same difficulties
[11:03:34] <crw-ietf> Carl notes that fixing thisUpdate also runs afoul of 3280
[11:03:43] <crw-ietf> (that's why this is in appendix)
[11:03:54] <yhetheridge> plus, OCSP has longivity issues for archiving
[11:03:59] <crw-ietf> back to Carl's earlier question: are these 2 drafts appropriate for this WG?
[11:04:13] <crw-ietf> Carl thinks they're both appropriate and necessary for what we're trying to achieve
[11:04:15] <chokhani> OCSP being a single response and small amount of data, you can jusitify storing a specific response with the ERS
[11:04:37] <chokhani> Should be coordinated with PKIX
[11:05:32] <crw-ietf> now on the "Milestone Organization" slide
[11:05:36] <tobias> would more recommend to store the OCSP directly in the signature/timestamp with normal PKIX means
[11:05:40] <crw-ietf> Milestones deck
[11:05:41] <greg> "conventional CRLs" may be very different in 10 years
[11:06:02] <greg> yes, at least as a MAY
[11:06:27] <crw-ietf> Any objection to suspending notary work and trying to wrap up ERS and LTAP?
[11:06:32] <crw-ietf> none from the room here?
[11:06:34] <greg> MAY use OCSP but RECOMMEND use historical CRL
[11:06:45] <tobias> no objection - full agreement
[11:06:53] <yhetheridge> agree
[11:06:55] <masinter> no objection
[11:07:53] <crw-ietf> discussion of "Proposed New Milestones"
[11:08:41] <tobias> would prefer earlier milestone for ERS - as already several products need to go to market....
[11:08:55] <crw-ietf> Russ asks if we can word this as "remove notary unless someone jumps in and work on it" rather than "TBD"
[11:09:42] <crw-ietf> @tobias: russ and carl say start WG last call next week and see how questions are answered
[11:10:09] <tobias> ok, thanks.
[11:10:21] <crw-ietf> if there are no more questions, meeting is adjourned
[11:10:28] <crw-ietf> (none in the room)
[11:10:34] <masinter> thanks for scribing
[11:10:37] --- yhetheridge has left
[11:10:40] <greg> thanks
[11:10:41] --- chokhani has left
[11:10:41] --- masinter has left
[11:10:42] <crw-ietf> no problem.
[11:10:43] <crw-ietf> bye all
[11:10:54] <tobias> thanks a lot for scribing!
[11:11:02] --- greg has left
[11:11:25] <isaaclan> bye all
[11:11:34] --- crw-ietf has left
[11:11:51] --- isaaclan has left
[11:13:55] --- tobias has left
[11:14:12] --- jimsch1 has left
[11:47:42] --- scasas has joined
[11:53:30] --- crw-ietf has joined
[11:54:05] --- dcrocker has left
[11:55:47] --- crw-ietf has left
[12:33:02] --- scasas has left: Replaced by new connection
[12:33:57] --- scasas has joined
[12:41:00] --- scasas has left
[12:59:30] --- LOGGING STARTED
[13:03:30] --- LOGGING STARTED
[13:11:38] --- dcrocker has joined
[13:30:02] --- dcrocker has left
[14:14:11] --- dcrocker has joined
[14:57:57] --- dcrocker has left
[15:08:36] --- dcrocker has joined
[16:01:27] --- dcrocker has left
[17:05:48] --- dcrocker has joined
[17:57:36] --- dcrocker has left
[18:54:49] --- dcrocker has joined
[19:28:54] --- dcrocker has left
[19:57:49] --- dcrocker has joined
[19:59:04] --- dcrocker has left