Re: crypto-ISSUE-14: Representation of raw key material [Web Cryptography API]

On Mon, Aug 27, 2012 at 2:54 AM, Vijay Bharadwaj
<Vijay.Bharadwaj@microsoft.com> wrote:
> I think you're over-interpreting my statement here - it was not as fully-fleshed-out a proposal as this. The point I was trying to make was much more limited - that it would be great if, where possible, new JSON formats stuck to the same field names as the existing ASN.1 modules. This would avoid creating lots of new names for the same things, and perhaps even simplify the task of creating new JSON types in future, as practice would establish a "natural" way of doing this.


To make sure I understand, your preference is that IF a direct JSON
encoding is provided (Option 2), then the format and structure should
match the ASN.1 equivalent?

eg:

interface RSAPublicKey {
   readonly attribute UInt8Array modulus;
   readonly attribute UInt8Array publicExponent;
}

interface OtherPrimeInfo {
  readonly attribute UInt8Array prime;
  readonly attribute UInt8Array exponent;
  readonly attribute UInt8Array coefficient;
}

interface RSAPrivateKey {
  readonly attribute UInt8Array version;
  readonly attribute UInt8Array modulus;
  readonly attribute UInt8Array publicExponent;
  readonly attribute UInt8Array privateExponent;
  readonly attribute UInt8Array prime1;
  readonly attribute UInt8Array prime2;
  readonly attribute UInt8Array exponent1;
  readonly attribute UInt8Array exponent2;
  readonly attribute UInt8Array coefficient;
  readonly attribute sequence<OtherPrimeInfo> otherPrimeInfos;
}

Is this correct?

JWK has already opted *not* to use the common naming, explicitly
because it's intended to be a wire format - and particularly, one that
is friendly to being passed in URLs (where strings longer than
1024/2047 bytes are typically problematic)

I would agree though that if we're exposing these as JSON objects (and
I can see compelling reasons to do so), keeping consistency with their
relevant specification - either the algorithm definition or relevant
IETF specs - is highly preferable.

Received on Monday, 27 August 2012 23:06:17 UTC