Re: Random Comments

Hi Jim,

Thanks for your quite detailed comments. I've attempted to respond to
them below as briefly as possible, but apologies if the brevity
appears as brusqueness. I think there's still a few items I need to
better understand, so I'm hoping you can provide further comments.

On Thu, Apr 18, 2013 at 9:30 AM, Jim Schaad <ietf@augustcellars.com> wrote:
> 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.

The goal is the latter group. To provide sufficient flexibility to
allow a variety of solutions to be explored.

>
> 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”

Could you explain this more? It combines something you have (A browser
with a previously registered keyset) with something you know (a
password or passphrase).

>
> 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.

Thanks. I will see if I can clarify this further.

>
> 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.

I think that's out of scope for this document / web APIs in general.
That's about a security consideration outside of the control or realm
of the browser application.

>
> 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}}

We're aware of this, and have significant discussion about this.

>
> 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)

Could you expand this comment further? Are you talking about natures
like CryptGetKeyParam / BCryptGetProperty?

I'm extremely mixed on the general purpose utility of these, and
having asynchronous property bags of arbitrary naming seems like even
more complexity for what is otherwise known values.

>
> 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”

Could you explain how you came to that conclusion or how you see the
difference and/or do you have alternative text to propose? AES-KeyWrap
is not presently defined (nor is any key wrapping), so I'm just trying
to understand this conclusion.

In the proposal from Netflix regarding Key Wrap, the caller still
specifies the algorithm used to generate the underlying wrapped key
material, and this would seem to be unambiguous.

>
> 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?

Tainting, yes.

Could you please explain what you mean by "in use" flag, since that's
not defined in the spec? Perhaps you're confusing with
CryptoOperation?

>
> 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.

Given that the currently defined CTR mode takes the initial counter
value as part of its initialization, it certainly is prescriptive for
purposes of CTR. This matches other cryptographic APIs (including CAPI
and and CNG), in which new instances of operations must be created to
alter counter values.

Given that the API is asynchronous, I don't see any reasonable
alternatives other than making it prescriptive. I would not want to
see an API that required both the input and output be returned to the
caller on every call.

That said, the transition to DOMFutures MAY allow this to be clearer
(by yielding distinct resolvable futures for given inputs), although
I'm very skeptical that this would work in practice.

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

We removed such state checks. There appear to be a few residuals that
need to be cleaned up.

>
> 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

It's an editorial note because this is still an issue under discussion.

>
> 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?

Presently an inconsistency that will need to be resolved. Thanks for flagging.

>
> 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?

No. Firing oncomplete should not happen until finish has been called.
Otherwise it's not possible to re-use a CryptoOperation between turns
of the EventLoop, due to potential races in handling data, which is a
key feature to be supported.

The issue here is simply a matter of clarifying that step 4 runs
during the asynchronous portion that follows after the invoking task
has been returned (eg: the algorithm continues for steps 3 and 4, but
immediately returns).

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

That's already handled by 12.4.3.3 - all notifications are queued as
tasks, and those tasks are removed.

>
> 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.

See above. Already handled without exposing.

>
> 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..

I'm sorry, I am having trouble understanding your concern here. As I
understand the implications, it seems that you feel that "encrypt" and
"decrypt" (as "sign" and "verify") should be restricted only to a
high-level API only? Is that so?

I don't agree with your comment about sign -> mac, especially since
since sign() is used to process asymmetric operations. I don't think
any developer reasonably expect such an operation to be called mac().

>
> 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.

These are not synchronous operations. They yield a CryptoOperation
that callers must still register callbacks on (present) or use
DOMFutures (next draft).

The point of enqueing tasks is to ensure that the caller has an
opportunity to attach callbacks, since they can modify (or potentially
abort()) the CryptoOperation, since no further tasks will be processed
until the callers' turn has ended.

There is absolutely no synchronous API provided, nor are there any
plans to provide one.

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

No it does not.

>
> 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.

Section 13 clearly shows KeyOperation as having "readonly attribute any result".

Perhaps I misunderstood your point?

>
> 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?

The spec is the registry.

>  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?

Updates to the spec, which require WG action.

Vendors that wish to support algorithms before they're part of any Rec
Track document should be treated as every other experimental web
feature, as that vendor sees fit. This is, again, no different from
how HTML WG and WEBAPPS WG have worked successfully for years without
issue.

>
> 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

I don't have particularly strong feelings about this, other than the
choice of RSASSA-PKCS1 and RSAES-PKCS1 are to provide clear
disambiguations between a key marked as "RSA-PKCS1" - since the latter
would imply a key that could be used for encrypt/decrypt and
sign/verify, which would be fatal to the overall security.

RSA-OAEP and RSA-PSS do not share a need for such disambiguation,
because they can clearly only be used with particular operation pairs.

In this regard, I think brevity wins here, and I don't believe it will
represent any confusion. If anything is abberant, it would be the use
of RSASSA-PKCS1 and RSAES-PKCS1, and if you see a way to resolve
those, I'm all ears.

Received on Thursday, 18 April 2013 23:05:01 UTC