Re: (Minor) New version published

On Mon, Aug 27, 2012 at 2:59 AM, Vijay Bharadwaj
<> wrote:
> First, thanks for writing this up. A few comments follow (these are in addition to the comments I sent on the other threads).
> I'm not sure I understand the second paragraph of 5.1. Is this simply warning against the possibility of a local DoS by an application requesting too many expensive operations,  or something more?

Yes. The risk is DoS in terms of CPU usage, or, for some
implementations that may store keys in secure elements, DoS in terms
of key storage.

It was mostly raised based on past experience with implementations'
handling of <keygen>

> Regarding enum KeyUsage: did you intend HMAC keys to use "sign" and "verify" as well?

Yes. Is this a concern?

> For import/export, why is KeyFormat an enum? My understanding is that this would preclude implementations from implementing other formats. I think we should let this be free-form for the same reasons that we allow arbitrary algorithm extensibility.

I don't think an enum is necessarily at odds with extensibility. An
update to this spec can extend the valid identifiers for the types
used and defined here. Any unsupported type has a well-defined failure
handling (in so much as it's converted to the empty string).

> Why does importKey take a key as a parameter? Is that the (optional) wrapping key? Correspondingly, how do I specify a wrapping key to exportKey?

"key" is the raw data to be imported, the format corresponding to the
KeyFormat "format"

So, as presently specified, importKey/exportKey don't have good
semantics for wrap/unwrap (which may or may not need to be separate

I raised ISSUE-35 to track this.

> How is deriveKey supposed to work, specifically with regard to the optional derivedKeyType parameter? For instance, if I specify the derivedKeyType as RSA, what happens? (You may see where this is going - as I've mentioned before, existing KDFs are basically just deterministic random bit sequence derivers - turning this bit sequence into a key takes a lot of work and not all native APIs expose this.)


I raised ISSUE-36 to track this.

> Where possible, can we reuse names from ASN.1 modules for algorithm parameters? E.g. use publicExponent instead of exponent for RSA, following RFC 3447. I can do a pass through the others to pick specific names if you like.
> Why do you require ASCII names for algorithms (in the normalization rules), instead of allowing UTF-8 or something else which would support non-English algorithm names?
> -----Original Message-----
> From: Ryan Sleevi []
> Sent: Wednesday, August 22, 2012 2:11 PM
> To:
> Subject: (Minor) New version published
> As per our conference call, all of the ISSUE-XX/ISSUE-YY pseudo-issues have been filed as proper issues in the issue tracker.
> As a reminder for everyone reviewing, please be sure to raise concerns on the mailing list, rather than waiting for our next conference call.
> Directly filing an ISSUE is an alternative, since it will also mail the list, and we can make sure to track the discussion and resulting text.
> We don't need to immediately begin discussing ISSUEs, but I want to make sure that everyone's objections and concerns are properly captured as we move forward.

Received on Tuesday, 28 August 2012 19:50:51 UTC