OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [office] RE: Visible Hashes and PBKDF2


Here are the issues that I've tracked about *:protection-key and
*:protection-key-digest-algorithm [no -name, I misspoke in my "medley" post
to the list]. These are in order by the section of ODF 1.2 CD05 Part 1 that
is involved.  These changes leave room for introduction of smarter
key-verification algorithms and their supporting data, but do not specify
any smarter ones.  I figured we needed to have a way to develop improved
techniques, their specification, and their agreed use over the life of ODF
1.2 and beyond.  The adaption of a PBKDF2 technique as a password verifier
was beyond my imagining, but I can see it used by mutual agreement and
implementation-defined profile, building on the provisions that are in ODF
1.2.

 - Dennis

19.698.4 table:protected attribute of <table:table>
  OFFICE-2639 Mostly applied in CD05, 
      <http://tools.oasis-open.org/issues/browse/OFFICE-2639>
  OFFICE-3505 Is a subtask that fixes additional aspects noticed reviewing
OFFICE-2639 as it shows up in CD05.  In particular, it was inappropriate to
say, here, anything about what table:protection-key holds. OFFICE-3505
removes that.

19.699 table:protection-key 
 OFFICE-2561 Applied in CD05 (was to get base64Binary as the datatype,
rather than string)
 OFFICE-2562 Applied in CD05 (established that it is UTF-8 representation of
the password that is hashed)
 OFFICE-2639 Mostly applied in CD05 (also to 19.698.4)
 The current approach is that table:protection-key is data required for the
verification of the password, but it is not confined to being a direct hash.

19.700 table:protection-key-digest-algorithm
 OFFICE-2563 Lobbied against introducing more straight-hash algorithms
because of the theater aspect and was abandoned in favor of OFFICE-2639
 OFFICE-2639 Mostly applied in CD05, allowing for table:protection-key being
data required for password verification but that algorithms could be more
sophisticated than plain hashes
 OFFICE-3505 Catches some things that OFFICE-2639 missed, including an awful
phrase that I was the author of

19.852 text:protection-key
  OFFICE-2561 as for table:protection-key
  OFFICE-2562 likewise
  OFFICE-2639 again
    
19.853 text:protection-key-digest-algorithm
  OFFICE-2563 as for table:protection-key-digest-algorithm
  OFFICE-2639 likewise
  OFFICE-3142 raises issues around implementation-specific from ODF 1.1 and
what we need to replace it with in ODF 1.2 (applied in ODF 1.2 CD03 Part1
editor-revision 03, but I haven't checked)
  OFFICE-3505 makes the same catch-up repair as for
table:protection-key-digest-algorithm
 
 
 

-----Original Message-----
From: David LeBlanc [mailto:dleblanc@exchange.microsoft.com] 
Sent: Monday, November 01, 2010 13:37
To: dennis.hamilton@acm.org; 'Hanssens Bart'; 'ODF TC List'
Cc: Rob Weir
Subject: [office] RE: Visible Hashes and PBKDF2

What's the issue number tracking this?

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Sunday, October 31, 2010 10:20 AM
To: 'Hanssens Bart'; 'ODF TC List'
Cc: Rob Weir; David LeBlanc
Subject: Visible Hashes and PBKDF2

Bart, David, and Rob

I see this on-list exchange as a matter of mutual education on the context
and what the existing provisions are.  There is no particular problem
although there are a couple of wordings in CD05 that reflect incomplete
resolutions of some issues (some effected wordings were not caught in the
resolution).  

There were previous issues on this topic and I also did considerable
analysis.  There might need to be a branch off of a previously-resolved
issue to correct some small glitches that have crept into later drafts of
ODF 1.2 where it can be seen that the application of previous resolutions
needs further adjustment (e.g., remove contradictions because a related
paragraph was left unchanged).  But the intention has already been reflected
in existing JIRA issues, and the adjustments I see now are quite
straightforward.

   *   *   *   *   *   *   *   *

With regard to having a URI for PBKDF2, the problem is that PBKDF2 is not a
single method, it is a framework of methods.  Finally, there is no mention
of PBKDF2 in [xmlenc-core], which is what we have been using.

[ ... ]

That's why the *specific* parameterization of PBKDF2 that is used with the
ODF Blowfish CFB has been spelled out in the ODF 1.2 update on the legacy
encryption algorithm.  (I need to check how much the existing JIRA issues on
this are reflected in the current CD05 editor draft and make sure the
resolutions are completed.  That's one of my commitments for today.)
 
 - Dennis

-----Original Message-----
From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be]
Sent: Sunday, October 31, 2010 02:13
To: David LeBlanc; dennis.hamilton@acm.org; 'ODF TC List'
Subject: RE: [office] The problem of visible hashes for protection keys

David,

> I do not know if there's an algorithm URI for PBKDF2, but seems like 
> there
ought to be.

There is one in XML-ENC 1.1:  http://www.w3.org/2009/xmlenc11#pbkdf2

(or did you mean in the ODF spec ?)


Best regards

Bart
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]