Random Comments

The following represents a series of random comments that are triggered by
having read the most recent (27 Jan 2013) W3C Editor's draft of the Web
Cryptography API document.

 

1.        I am having a problem understanding the target audience of this
document in terms of the expected experience level and cryptographic savvy
of a reader and user of this API document.  There are many time where the
process of going from A to B seems to be either overly complicated (can't
use a key object as the public key value in a key agree) or overly
simplified (no real difference between mac and sign).   In order to
correctly gauge the level of comments it would be helpful if there was a
section on target audience for the document that covered a level of
sophistication and background that is expected for users of this
specification.  I guess part of the question is - does this document focus
on the developer who should be able to do something crypto in an afternoon?
Or does it address people like me - I need to be able to do just about
anything because I am doing all sorts of prototyping of new cryptographic
algorithms, techniques and protocols.

2.       In section 2.1 - there is almost nothing in this use case that I
recognized as being multi-factor authentication.  The only thing that comes
close would be the addition of cryptographic channeling binding from the TLS
session as part of the authentication process.  I would strongly suggest
either actually giving cases of multi-factor authentication or changing the
section title to something like "Multiple authentication methods"

3.       In section5.2 the last paragraph, I don't understand how the final
clause in the sentence is supposed to make sense.  The use of existing
cryptographic messaging protocols does not preclude the signing of arbitrary
messages.  The messages may still be arbitrary just formatted in a
well-known formation.

4.       Section 5 - I am wondering if there is something that should be put
into this section about positive cleanup/care that needs to be dealt with in
the situation of a public workstation as oppose to a user's machine.
Leaving keys around that can possibly be used by others is always a bad
idea.

5.       Section 10 - Issue-28 - This is not a comment about the question of
permitting short-names.  I will however note that the proposal of allowing
for parameter values to be set as constants with a short name corresponds to
the path that the JOSE working group has currently taken.  Thus RSA-PSS-SHA1
would map to {'name':'rsa-pss', 'params': { 'hash': {'name':'sha1'},
'mgf':{'name':'mgf1'}, 'saltLength':20}}

6.       Section 10 - One of the things that I have found very useful in
both Microsoft CAPI and Microsoft CNG is the fact that there are some
constants that are published as part of the interface so that one can get
information about an algorithm.  Examples would be the key sizes of an
algorithm, the size of an IV to be generated, what things are fixed based on
the algorithm chosen (i.e. RSA-with-SHA1 means a specific hash algorithm)

7.       Section 11.2 - The description of algorithm appears to me to be
incorrect.  Is this supposed to be the algorithm that was used to generate
the key or the algorithm associated with the key?  An example of the
difference would be the difference between AES, AES-KeyWrap (and maybe
AES-CBC).  You can use AES-KeyWrap to unwrap a key - the current text
implies that this means the algorithm would be set to AES-KeyWrap rather
than either AES or "binary secret"

8.       Section 11.3 - There is an implication of step 4 that I would like
to tease out.  If you are cloning a key, does that mean that the tainting
that was discussed previously would occur on both key objects?  Similarly
would a "in use" flag in the key be set for both keys at the same time?

9.       Section 12.1 - Is the requirement on the queue being a FIFO queue
prescriptive or descriptive?  I know of algorithms such as CTR mode and tree
hash functions where this is not a hard requirement on the algorithm
implementation.

10.   Section 12.1 - Do you want to start with an internal state check as
the first step in the algorithm?

11.   Section 12.1 - Step #3 (update result) I would not have necessarily
thought of this as an accumulation operation without the following Editorial
note.  I would suggest that this fact be explicitly stated in the
description of the step

12.   Section 12.3 - result says that for an error then the result must be
NULL - does that need to be added to the algorithm in section 12.1?

13.   Section 12.4.2 - The finish method states that the cryptographic
operation is to be done async, however step 4 would appear to be a sync
event.  Should this processing (firing the oncomplete event) be moved to
section 12.1?

14.   Section 12.4.3 - Should this function do anything for any currently
existing notifications?

15.   Section 12 - Should the internal state be visible to the external
world?  There are currently some interesting conditions that can occur - For
example one can cue an onprogress notification, immediately follow it with
either an abort or a processing error which clears the result and then
process the onprocess notification - there is no result and no indication of
why this would be true.

16.   Section 15 - What can I say - I really dislike the first four
functions in the SubtleCrypto interface.  I would far prefer that these
function names did not carry any cryptographic connotations unless they are
going to have some type of restriction to those connotations.  I do not
believe and have needed over the years to correct any number of
misconceptions dealing with the difference between sign and mac.  Using
names such as transform/untransform and compute/verify would make me much
happier.  However I would appreciate even something as small as changing the
function sign to mac.  Since everybody keeps telling me that they are close
enough to the same then there should not be any real pushback on such as
small change..

17.   Section 15.2.1 - I am unclear why step #4 specifies that the process
and finish calls are to be done via a queued task rather than simply
directly calling the functions here.  Given that process and finish are
async operations these would not be blocking.  Note that this fact is
completely against the first line in the Editorial note that follows which
suggests that these operations should be synchronous rather than
asynchronous.

18.   Section 15.2.6 - Steps 4 and 5 should be reversed.   One needs to do
the queue before doing the return.

19.   Section 15.2.6 - I don't think that you are currently publishing a
result for KeyOperation  Thus step 5.5 would appear to be incorrect.

20.   Section 20.2.1 - The use of a canonical name for an algorithm implies
to me a registry for the canonical names.  Is such a registry planned and
what are the registration procedures for this going to be?  Is this going to
be a first publish registry in that if Mozilla publishes a new algorithm
with a specific name that becomes the canonical name?

21.   Section 20.5 - I would have expected the name of this algorithm to
match that in section 20.4 and thus it would be RSASSA-PSS

22.   Section 20.6 - RSA-OAEP should be RSAES-OAEP