ODF Agenda for 4 June 2018 - prior discussions are inline

[Patrick Durusau <patrick@durusau.net>]

Greetings!

I trust everyone enjoyed the long break!

I have inserted prior chat logs where relevant so we won't have to spend time finding the prior discussions. Please review before our meeting.

Below you find a draft agenda for our TC call on Monday, 2018-06-04

The call counts towards voter eligibility.

Teleconference Numbers

Canada - (use US number)

Denmark - +45 78 77 25 34

Germany - +49 30 255550324

Hungary - +36 1 987 6874

The Netherlands - +31 6 35205016

USA - +1 641-715-3580

Access code (for all numbers): 438-387

Chat room for meeting is at: http://webconf.soaphub.org/conf/room/odf

Please send comments to the mailing list.


Agenda
------

1. Dial-In, Roll Call, Determination of Quorum and Voting Rights

2. Motion (simple majority): Approve the Agenda

3. Motion (simple majority): Notice of minutes from prior TC calls - pending

4. Meeting time for 4 June 2018 - https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018&month=6&day=4&hour=16&min=0&sec=0&p1=25&p2=37

5. Issues for 4 June 2018:

Remaining from Michael's short list:

i. https://issues.oasis-open.org/browse/OFFICE-2093 Using URL fragment identifiers for ODF media types (was discussed 20 Feb 2017)

From 20 Feb 2017:

*****
Michael Stahl: https://issues.oasis-open.org/browse/OFFICE-2093
Jos van den Oever: http://example.com/data.csv#cell=4,1-6,2
Jos van den Oever: https://tools.ietf.org/html/rfc7111
Jos van den Oever: soffice 'file.ods#text|searchterm'   does not work ...
Svante Schubert: text:name is of type string
Svante Schubert: xml:id is of type ID
Svante Schubert: We should be careful when allowing text:name due to
encoding problems as part of the frament identifier and its multiple
usages (first might be taken)
Patrick: consumer requirements - shall would be inappropriate (Michael)
perhaps a should?
Patrick: Michael, no reason to limit to text documents -
Svante Schubert: mypresention.odp#1
Svante Schubert: similar something for spreadsheets and cells & cell-ranges
Michael Stahl: i think it's mypresentation.odp#page1 in OOo/LO
Svante Schubert: I will come up with a suggestion for presentation and
spreadsheet shortcuts - convention over configuration - to ease usage
Svante Schubert: NCName is https://www.w3.org/TR/xml-names11/#NT-NCName
Patrick: The practical restrictions of NCName are that it cannot contain
several symbol characters like :, @, $, %, &, /, +, ,, ;, whitespace
characters or different parenthesis. Furthermore an NCName cannot begin
with a number, dot or minus character although they can appear later in
an NCName.
Patrick: Svante and Michael will add to the issue and we will return to
it next week
*****


ii. https://issues.oasis-open.org/browse/OFFICE-3940 Add OpenPGP-based XML encryption (was discussed 4 Dec 2017)

From 4 Dec. 2017:

*****

Jos van den Oever: a. https://issues.oasis-open.org/browse/OFFICE-3940 Add OpenPGP-based XML encryption

Thorsten: https://www.w3.org/TR/xmldsig-core/#sec-PGPData

Jos van den Oever: https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-PGPData

Jos van den Oever: The xmldsig version of 2008 also references PGP.

Jos van den Oever: Patrick: in ODF we can already encrypt with PGP, but cannot store info on the public key that was used

Jos van den Oever: Thorsten: in email you have hybrid encryption, with a symmetric key. The session key is encrypted with all recipients public key.

Jos van den Oever: Thorsten: each recipient gets it's own version of the encrypted session key. This is a nice way to go about without needing an external communication channel.

Jos van den Oever: Thorsten: for signatures we are good, but encryption is still lacking

Jos van den Oever: Michael: i have an issue with password based encryption. It uses a different key for every file in the session. With many iterations, it takes a long time to get these keys for all files. We could restructure to use only one key per package.

Jos van den Oever: Michael: we could put one package in a zip file to have only one encryption.

Jos van den Oever: Thorsten: the only thing to retain AES initialization vector and keep that for every file.

Jos van den Oever: Michael: init vectors is why we run KDF once per file.

Jos van den Oever: Jos: does KDF take so long?

Jos van den Oever: Michael: yes, because hashing would be run on cpu and that's fine, but now we have gpus' and they are much faster and in parallel. So we need more iterations to avoid brute-forcing.

Jos van den Oever: Thorsten: with a public/private key this issue is not present.

Jos van den Oever: Michael: yes this is an issue only with passwords

Jos van den Oever: Thorsten: so you want to have key-derivation attribute out of individual files?

Jos van den Oever: Michael: yes, have an inner package with the encrypted content

Jos van den Oever: Jos: so for password encryption it's beneficial to have a single encrypted package file

Jos van den Oever: Michael: yes

Jos van den Oever: Thorsten: unf that's a larger rearchitecturing

Jos van den Oever: Thorsten: the initialization vector was added because you might have many files starting with the same 16 bytes.

Jos van den Oever: Thorten: one blob with encrypted content solves that issue

Jos van den Oever: Thorsten: as to PGP/GPG support is just piggybanking on the existing encryption software, with the main part still being symmetric

Jos van den Oever: Jos: do you create a new file for each recipient or put encrypted keys for each recipient in the file?

Jos van den Oever: Thorsten: we put the encrypted keys for each recipient in the file

Jos van den Oever: Jos: so you can see in the file who are the recipients

Jos van den Oever: Thorsten: the key id / key fingerprint is required

Jos van den Oever: Thorsten: for x509 key package is usually also included

Jos van den Oever: Jos: would it make sense to keep the asymmetric receiver specific part external to the odf document?

Jos van den Oever: Thorsten: it's easier to keep it all in one place

Jos van den Oever: Thorsten: anything that is out of band may be lost

Jos van den Oever: Jos: are we sure things are missing?

Jos van den Oever: Patrick: at the time, just password protection seemed enough, promoting encrypting is the right direction

Jos van den Oever: Patrick: i'm not sure this proposal goes far enough or if we need something more substantial. Can we get a lot of benefit with small effort. Would we have a good differentiator with other systems?

Jos van den Oever: Thorsten: the current proposal is the minimal change we need

Jos van den Oever: Thorsten: conceivable we could go to x509 if there's a sponsor for that, to cover most prevalent encryption systems

Jos van den Oever: Michael: feature is a good idea, unf cannot read schema diff due to jira mangling it.

Jos van den Oever: Thorsten: email to the list should have better (no) formatting

Jos van den Oever: Michael: i did get the mail, even though it's broken for Thorsten

Jos van den Oever: Michael: but the no-formatting does not work because enabling it would have consequenced for all current comments

Jos van den Oever: Regina: can you make an example manifest.xml?

Jos van den Oever: Thorsten: ok

Jos van den Oever: Patrick: this is now an open issue for odf 1.3
*****

iii. https://issues.oasis-open.org/browse/OFFICE-3665 Allow data pilot source cell range to be referenced by textural name.


iv. https://issues.oasis-open.org/browse/OFFICE-1148 Demand for modification of ODF file format about regression curvein
spreadsheet (was discussed 2 Oct 2017)


Patrick: https://issues.oasis-open.org/browse/OFFICE-1148
Patrick: What of gnumeric and Excel?
Patrick: MS-Excel support all these points since MS-Excel 5.0 (for
MS-Windows 3.1, it was in 1993)
Gnumeric support polynomial regression curve in version 1.6 and moving
average regression curve in version 1.9.
LibreOffice extended ODF 1.2 to support all these points in version 4.2.
Patrick: Andreas will check against Gnumeric and - send email to Aarti
asking about Excel


****
I've added:

v. https://issues.oasis-open.org/browse/OFFICE-3937 Remove restrictions from drawing page style


6. Next meeting: 2018-06-11.

7.  Adjournment

Hope everyone is at the start of a great week!

Patrick

-- 
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau

Attachment: signature.asc
Description: OpenPGP digital signature