W3C home > Mailing lists > Public > public-webcrypto@w3.org > July 2012

RE: ISSUE-3: Algorithm discovery

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Sat, 21 Jul 2012 00:36:37 +0000
To: Ryan Sleevi <sleevi@google.com>
CC: Lu HongQian Karen <karen.lu@gemalto.com>, Anthony Nadalin <tonynad@microsoft.com>, Mike Jones <Michael.Jones@microsoft.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, David Dahl <ddahl@mozilla.com>
Message-ID: <382AD43736BB12439240773F68E907739E57C9@DF-M14-22.exchange.corp.microsoft.com>
> If I were writing an application that was meant to be a "secure messaging" application, I know that as the app developer, I would want "All keys capable of signing", since as a provider, I don't care /how/ the message is signed. Once I was granted access to that key, the exact signing context I used with that key (DSA, RSA-PSS, RSA-PKCS) would need to be discovered somehow.

My assertion is that this isn't possible in a low-level API.

In a low-level API you are going to have to deal with the fact that the same operation requires slightly different handling with each algorithm. For instance, RSA-PSS may require a salt size which RSA-PKCS doesn't. So your app is going to have to know the quirks of a certain set of algorithms, and look only for keys that support that set of algorithms. So that leaves your other cases, which are all essentially querying keys based on key metadata that indicates what algorithms they can be used with; this is generally supported in many crypto APIs.

This changes if you have a high-level API, but in that case an app developer would arguably be much happier with "sign this for me" rather than having to do key selection, etc.

> For a given key handle, what attributes are likely to be exposed to applications?

I think this is a very important question. In my mental model, for a key that is accessible to an application, the algorithm and type (e.g. asymmetric signature/RSA) are likely to be generally available without prompting. The much bigger issue is access control (as motivated by privacy concerns that you have mentioned before). I suspect that for that reason you'd have to have some UI shown for the key query but it should be once per query and not dependent on the number of keys.

On a related note, I think it is important that we support the use of a single key handle with multiple CryptoOperations. Key open is often expensive (e.g. it may require locating the key on a network or hardware module) and for example with smart cards PINs are often cached on a key handle. So if a user is trying to complete a transaction that requires multiple crypto operations, you want this to be done without multiple PIN prompts.

>  - Does the caller create a new CryptoOperation, register callbacks, call .init(), and then check to see if onerror was called? If it "works", how does the application know? Is .onprogress called? Is there some new event that now needs to be exposed, such as oninit()?

Yes, this is what I had in mind. Essentially create a new CryptoOperation, register callbacks and wait for onready() or oninit() to be called.

> More practically speaking, any form of exchange between two parties where they want to discover the union of supported /KEYED/-algorithms, with no pre-existing keys, and without requiring them to .generate() every possible key (since key generation may be computationally expensive).

I think we are actually in agreement on this aspect. This needs algorithm discovery in the limited sense that I talked about. Instantiate a CryptoOperation for the key generation, and if you succeed then proceed with the key generation.

> In my proposal for .init(), I think I've come to see it as as a replacement for discovery - that is, fully remove .supports(). It was possible to see if an operation was possible or not (ie: seeing if .onerror was triggered). This is, in effect, a replacement for .supports(), specifically to handle asynchronous operating environments, which .supports() as proposed did not.

Yes, I think we are largely in agreement here. In my mind the remaining issue is whether we need an explicit .init or whether we use a RAII-type paradigm which makes it implicit.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Monday, July 16, 2012 5:58 PM
To: Vijay Bharadwaj
Cc: Lu HongQian Karen; Anthony Nadalin; Mike Jones; public-webcrypto@w3.org; David Dahl
Subject: Re: ISSUE-3: Algorithm discovery

On Mon, Jul 16, 2012 at 11:58 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote:
> Karen beat me to it, but I was also using .init() as a shorthand for such an implicit initialization (as I thought you were too, thanks for pointing out the misunderstanding).
>
> I think there are multiple issues here that may need to be separated. First, I think we need some model of stored keys. In my mental model, key discovery doesn't require user interaction other than for domain ACL reasons - it is a question of locating a key based on name or other metadata, and querying potentially other metadata which are not secret.
>
> The other issue, I think, is some model of what an application might want to do with discovery. Broadly, it seems to me that an app either wants algorithm discovery or key discovery, but not both.
>
> - Algorithm discovery: my app is trying to perform operations in an algorithm that it (or the server it talks to) supports using no keys or ephemeral keys. In this case a check based on instantiating a CryptoOp or similar object works just fine. I'm not sure explicit discovery is needed here.
>
> - Key discovery: my app is either trying to find a specific key it created (e.g. by name or issuer) or a specific type of key supporting a given algorithm (e.g. by querying for certificates). The operation I am doing requires this key, so if it fails I'm going to error out anyways. So I will try to locate the key and perform the operation I have in mind, and if I fail I will error out. The level of key access required for this should not require prompting (except perhaps for privacy reasons as supported by domain ACLs, but that seems unavoidable in any case).

"Supporting a given algorithm" is a complex problem, which is why I think some form of discovery (explicit or implicit) is important and required.

For example, consider message signing, using pre-existing keys (not pre-provisioned, /pre-existing/).
- Does an application query for all keys capable of signatures?
- Does it query for all RSA keys?
- Does it query for all RSA keys of a particular (minimum? maximum?
exact?) size?
- Does it query for all RSA keys of a particular size supporting a particular signature algorithm (eg: PSS, PKCS#1 v1.5)
- Does it query for all RSA keys of a particular size supporting a particular signature algorithm supporting a particular hashing algorithm (eg: SHA1, SHA2-256, SHA2-384)

If I were writing an application that was meant to be a "secure messaging" application, I know that as the app developer, I would want "All keys capable of signing", since as a provider, I don't care /how/ the message is signed. Once I was granted access to that key, the exact signing context I used with that key (DSA, RSA-PSS, RSA-PKCS) would need to be discovered somehow.

For a given key handle, what attributes are likely to be exposed to applications?
- Whether a key is symmetric or asymmetric?
- Key size?
- What algorithm the key is for?
  - Is this simply "RSA"?
  - Or is it RSA-PSS?

If the key is backed by a (software, hardware) provider that only implements certain algorithms, how is this to be discovered?
 - Does the key have an attribute (.signing_algorithms[]) listing all possible permutations of signature algorithms?
 - Does the caller create a new CryptoOperation, register callbacks, call .init(), and then check to see if onerror was called? If it "works", how does the application know? Is .onprogress called? Is there some new event that now needs to be exposed, such as oninit()?

Even after an application has granted, on the domain ACL level, access to a key, I still think there may be other prompts. In particular, many (all?) OS store implementations have concepts of "prompt on every access". This helps users ensure that operations happen in response to user input, and not, say, some background malicious agent.

If there is no way to distinguish between "I'm trying to see if this is possible" and "I actually want to do this, for realzies", then the only response is to keep prompting the user, which is not ideal.

>
> I think what's needed is perhaps a counter-example of an app that, if given a list of algorithms that an implementation supports, can somehow use that information in a better way than just checking if the one or two algorithms it cares about are on the list.

TLS is one such example.

More practically speaking, any form of exchange between two parties where they want to discover the union of supported /KEYED/-algorithms, with no pre-existing keys, and without requiring them to .generate() every possible key (since key generation may be computationally expensive).

For example, if Alice wanted to send a message to Carol through Bob's service. Alice and Carol use different browsers, on different OSes, which run in different environments (Alice runs a full desktop-based browser, but operates in a constrained regulatory environment with a locked-down algorithm set, and Carol runs on a mobile device with memory and CPU constrains). Alice and Carol want to discover their union of supported algorithms, to decide what sort of keys to use for their initial key exchange.

As proposed, the only interface to doing so is to generate a key of every possible type that the application knows about, and then see which ones worked. My goal is to take out the "generate a key" phase, keeping discovery "cheap".


In my proposal for .init(), I think I've come to see it as as a replacement for discovery - that is, fully remove .supports(). It was possible to see if an operation was possible or not (ie: seeing if .onerror was triggered). This is, in effect, a replacement for .supports(), specifically to handle asynchronous operating environments, which .supports() as proposed did not.

As I understand Karen's proposal, .init() to her is so that an object can be recycled (or potentially restated, cloned).

Do either of these definitions meet your expectations? Or was there something else?

>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Monday, July 16, 2012 10:45 AM
> To: Lu HongQian Karen
> Cc: Vijay Bharadwaj; Anthony Nadalin; Mike Jones;
> public-webcrypto@w3.org; David Dahl
> Subject: Re: ISSUE-3: Algorithm discovery
>
> On Mon, Jul 16, 2012 at 10:32 AM, Lu HongQian Karen <karen.lu@gemalto.com> wrote:
>> In the low level API, one first gets a crypto operator (cryptostream)
>> and then uses it to processData(). For example, (from the spec)
>>
>> var cryptor = window.crypto.encrypt(algorithm, alice_key);
>>
>> If this operation fails, it means either the algorithm is not supported, alice_key has a problem, or some other reasons. So this does more than .support can do.
>>
>> Regards,
>> Karen
>
> Karen,
>
> I don't think that was the intent. window.crypto.encrypt() can
> certainly check for issues with the parameters specified in algorithm
> (eg: illegal values, unknown names, etc). It /may/ also be able to check that algorithm+alice_key can be used - or it may have to wait until .processData().
>
> However, it also has a number of limitations compared to the proposed
> .supports API
> - A caller must first obtain alice_key. If key discovery is required
> (eg: KeyQueryList or equivalent), then that may result in user
> interaction. If an application is trying to build up a list of
> supported algorithms, but does not immediately need them, this could
> potentially result in multiple prompts to the user. This would be
> unacceptable, I think, for all parties (browsers, application authors,
> users)
> - Even if a caller has alice_key, alice_key may be protected in such a way (ACLs) that every piece of data to be encrypted/signed requires user consent. By forcing discovery to happen via the actual operation, it again results in a situation where the user is repeatedly prompted.
>
> My goal in .supports or equivalent is to provide a means for an application to discover meaningful algorithms, optionally with restricting them to a set of keys, and none of which should require any additional user interaction or confirmation.
>
> This is somewhat related to the key usages conversation from earlier - in that I think discovering /how/ you can use a key/algorithm is somewhat orthogonal in purpose to /when/ you use the key/algorithm.
>
> Cheers,
> Ryan
>
>>
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: Wednesday, July 11, 2012 8:16 PM
>> To: Vijay Bharadwaj
>> Cc: Anthony Nadalin; Mike Jones; public-webcrypto@w3.org; David Dahl
>> Subject: Re: ISSUE-3: Algorithm discovery
>>
>> On Wed, Jul 11, 2012 at 5:46 PM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com> wrote:
>>> This distinction between keyless and keyed algorithms seems useful.
>>>
>>> Generally, I don't think it makes sense to ask whether a platform supports a given algorithm without other context, due to the reasons that Tony alludes to. Perhaps we should break down the problem:
>>>
>>> - For keyless algorithms (basically hashing) it is reasonable to ask if a particular algorithm is supported. However, in such a case, the .supports API looks exactly like the API for .init, so it adds little value. In this case, a successful .init would generally guarantee success of the operation except in exceptional cases.
>>> - For keyed algorithms, it is only reasonable to ask if a particular algorithm is supported with a specific key (because, as Tony mentioned, the key might be in hardware that limits what is allowed). Now since the programmer has to go through the effort of opening the key already, it doesn't seem like a .supports API adds anything - you might as well try to .init and see if you fail. In this case a successful .init is no guarantee of success, as smart cards may be removed, network connections may be lost, etc.
>>>
>>> So while I agree that an implementation might want to think about .supports as being a state, I can't see any reason to expose an API specifically for it.
>>>
>>> Regarding your earlier questions:
>>>
>>>>> 2) Do implementers/U-A's expect a need to prompt for operations (perhaps prompting for every .sign operation), or does the fact that the application have a key handle mean that they are authorized for as many operations as possible (related to ISSUE-2)
>>>>>   - If prompting is expected, when is it anticipated that this prompting will occur? Creation of the CryptoStream? The first call to .processData()? The final call to .complete()?
>>>>>   - If prompting happens, is it expected to happen for every operation (every .sign())? Once per browsing context? Once ever?
>>>
>>> Prompting behavior varies across implementations but prompting on the actual operation is most common. You should assume it is possible to hit a prompt on every private key operation - all the scenarios you mention above exist in real deployments.
>>
>> Initially, this is exactly why I was in favour of adding a .supports() API.
>>
>> However, even a .supports() may, independent of any browser-origin key ACLs, result in prompts from crypto libraries. For example, a PKCS#11 module that requires the user to be logged in to use a particular algorithm, or a CryptoAPI/CNG provider that requires user interaction before you can open the Algorithm provider.
>>
>> So .supports() as blocking is certainly insufficient, and .supports() as a way to avoid prompting realistically only avoids U-A prompting for domain-based ACLs. Since we don't yet know how ACLs will behave, I think removing .supports() is perfectly reasonable, and would hold off introducing .init() until we know how such ACLs (for both pre-provisioned and for new keys) should behave.
>>
>>>
>>>>> 3) What is the expected experience if an algorithm is not implemented/not supported.
>>>>>   - For the script (eg: what error handling facilities will exist)
>>>>>   - For the user (eg: might they be prompted to insert a smart
>>>>> card that does support the algorithm?)
>>>
>>> For keyless algorithms, if an algorithm is not supported, there is generally little a normal human user can do to remedy this. For keyed algorithms, if an algorithm is not supported with a key then you have to use a different key.
>>
>> Note that the current strawman does not have an explicit .init(), I was proposing it as a replacement for .supports(). I wasn't sure from your response if you thought this a better API alternative, or if you felt it had the same issues as .supports().
>>
>>>
>>> -----Original Message-----
>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>> Sent: Tuesday, July 10, 2012 4:50 PM
>>> To: Anthony Nadalin
>>> Cc: Mike Jones; public-webcrypto@w3.org; David Dahl
>>> Subject: Re: ISSUE-3: Algorithm discovery
>>>
>>> On Tue, Jul 10, 2012 at 4:39 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>>>> This does not help as the 4758 may not have a specific key to
>>>> support the specific algorithm but the 4758 may in general support
>>>> the algorithm
>>>
>>> Can you provide an example of a keyless algorithm, beyond hashing, where you would lack a specific key but would support a specific algorithm? Or are you specifically thinking of hashing?
>>>
>>> Or are you saying that if you have a raw key, and then import it into the device, THEN you could use AES-128-CBC? If so, I feel like that really goes into "key provisioning" APIs (when and how to get a key on the device), and that such problems may be out of scope.
>>>
>>> For what it's worth, for the "keyless algorithm" support, the equivalent calls would be BCryptOpenAlgorithmProvider or PKCS#11's CK_MECHANISM_INFO fields combined with enumerating a token's slots.
>>>
>>> If you're using IBM's raw APIs, and they lack algorithm-discovery equivalents, well, then you already know you're talking to a 4758 and then there is no special casing needed - your entire app is special-cased and you know all the supported algorithms.
>
>>>
>>>>
>>>> -----Original Message-----
>>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>>> Sent: Tuesday, July 10, 2012 3:14 PM
>>>> To: Anthony Nadalin
>>>> Cc: Mike Jones; public-webcrypto@w3.org; David Dahl
>>>> Subject: Re: ISSUE-3: Algorithm discovery
>>>>
>>>> On Tue, Jul 10, 2012 at 2:23 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>>>>>> My primary goal for discovery is not to provide an absolute, immutable commitment that algorithm X is implemented and will always be implemented, since errors happen and implementations will vary, thus such requirements may not always be guaranteed. However, I am trying to separate out the states of "Is this [user agent, key, operation] compatible with my application" and "Perform a specific operation on a key".
>>>>>
>>>>> Not sure how you actually do this with a HSM like a IBM4758 (or
>>>>> follow-on), as I have no way to determine if the keys held in the
>>>>> IBM4758 are compatible with the application, only way to know this
>>>>> is to develop the application with specific knowledge of what I'm
>>>>> putting in the IBM4758
>>>>
>>>> CNG (Windows)
>>>> NCryptEnumAlgorithms + NCryptGetProperty
>>>>
>>>> PKCS#11 (OS independent)
>>>> C_GetMechanismInfo
>>>>
>>>> Keychain Services (OSX)
>>>> kSecClassKey + kSecAttrCanWrap/kSecAttrCanSign + kSecAttrKeyType
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>>>> Sent: Tuesday, July 10, 2012 12:35 PM
>>>>> To: Mike Jones
>>>>> Cc: Anthony Nadalin; public-webcrypto@w3.org; David Dahl
>>>>> Subject: Re: ISSUE-3: Algorithm discovery
>>>>>
>>>>> Thanks, it's good to have actual examples to consider.
>>>>>
>>>>> With the example of a smart card - which can be extended to any number of smart-card independent key storage examples, such as network-based file key stores - a smart card being ejected can happen at any point during an operation. For example, during .processData(), before calling .complete(), or between creation of the CryptoStream and the first call to .processData().
>>>>>
>>>>> Logically, I would think of .supports() as thus being another state in that state machine - whether implicitly via a call to .supports() and then a call to .encrypt(), or explicitly, by making a .init() method on the CryptoStream prior to .processData().
>>>>>
>>>>> As such, I'm not sure how it's actually different from the error handling applications would already expect, and thus doesn't seem an argument against discovery.
>>>>>
>>>>> My primary goal for discovery is not to provide an absolute, immutable commitment that algorithm X is implemented and will always be implemented, since errors happen and implementations will vary, thus such requirements may not always be guaranteed. However, I am trying to separate out the states of "Is this [user agent, key, operation] compatible with my application" and "Perform a specific operation on a key".
>>>>>
>>>>> Since my arguments for discovery are hinged upon use cases that I believe are only enabled by algorithm discovery, perhaps it's better to rephrase the discussion and see what alternative proposals for addressing this are:
>>>>>
>>>>> 1) Should the low-level API protect users from mixing incompatible cryptographic primitives, such as sign+verify and encrypt+decrypt?
>>>>>   - If not, but the underlying key store does not allow them to be mixed, should applications be able to discover this?
>>>>> 2) Do implementers/U-A's expect a need to prompt for operations
>>>>> (perhaps prompting for every .sign operation), or does the fact
>>>>> that the application have a key handle mean that they are
>>>>> authorized for as many operations as possible (related to ISSUE-2)
>>>
>>>>>   - If prompting is expected, when is it anticipated that this prompting will occur? Creation of the CryptoStream? The first call to .processData()? The final call to .complete()?
>>>>>   - If prompting happens, is it expected to happen for every operation (every .sign())? Once per browsing context? Once ever?
>>>>> 3) What is the expected experience if an algorithm is not implemented/not supported.
>>>>>   - For the script (eg: what error handling facilities will exist)
>>>>>   - For the user (eg: might they be prompted to insert a smart
>>>>> card that does support the algorithm?)
>>>>>
>>>>> On Tue, Jul 10, 2012 at 11:41 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>>>>
>>>>>> For example, an algorithm could be supported when a smart card is inserted and not supported when it's removed, because the implementation is on the card.  Between the "discovery" step and the code trying to use the algorithm, a smart could have been removed by the user.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Tony may have other examples in mind.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>>>>> Sent: Tuesday, July 10, 2012 8:34 AM
>>>>>> To: Anthony Nadalin
>>>>>> Cc: public-webcrypto@w3.org; David Dahl; Mike Jones
>>>>>> Subject: Re: ISSUE-3: Algorithm discovery
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 10, 2012 at 7:38 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>>>>>>
>>>>>> Even with this approach you still don't know if the algorithm is
>>>>>> supported given the various input parameters
>>>>>>
>>>>>>
>>>>>>
>>>>>> I thought this concern had already been addressed, so can you provide an example of an input parameter that would not be able to be passed via .supports?
>>>>>>
>>>>>>
>>>>>>
>>>>>> I've identified the operation (encrypt/decrypt/sign/verify) as a known deficiency, but your reply and the past discussion suggest that there may be some other parameter/set of parameters not being considered, so it would be good to have a concrete example for the WG to consider.
>>>>>>
>>>>>>
>>>>>>
>>>>>> As demonstrated in the pseudo-algorithm-registry for the original strawman and in the current draft, parameters such as IV were to be passed via the Algorithm/AlgorithmParams dictionary.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>>>>> Sent: Monday, July 09, 2012 6:27 PM
>>>>>> To: public-webcrypto@w3.org
>>>>>> Cc: David Dahl; Mike Jones
>>>>>> Subject: ISSUE-3: Algorithm discovery
>>>>>>
>>>>>>
>>>>>>
>>>>>> In the original straw-man and current draft, I proposed an API
>>>>>>
>>>>>>
>>>>>>
>>>>>> bool supports(Algorithm algorithm, optional Key key);
>>>>>>
>>>>>>
>>>>>>
>>>>>> This was to allow determining whether or not a given algorithm was supported, without having to actually create a CryptoStream object. The intent was to provide a way to discover whether the necessary complete set of ciphers was available for an application, before beginning potentially expensive operations (key generation, data download, key discovery that may result in user interaction, etc).
>>>>>>
>>>>>>
>>>>>>
>>>>>> However, as some have pointed out, there are implicit facilities for algorithm discovery, by virtue of the fact that .encrypt/.decrypt/.sign/.verify need to have some well-defined behaviour for handling invalid or unsupported Algorithms. It has also been raised that whether or not a given algorithm is supported is dependent upon the key being used, although I believe I addressed that point via the optional "Key" parameter, since it allows a user optionally to determine if a particular key supports the algorithm, rather than just whether or not an implementation exists.
>>>>>>
>>>>>>
>>>>>>
>>>>>> However, I'm now thinking that the currently defined synchronous interface is neither desirable nor sufficient. It seems to me that, for at least some key storage types, determining whether or not a particular algorithm is supported may involve some form of user interaction or, in the case where key storage is backed by hardware, some form of hardware communication. For example, if using PKCS#11, this may involve calls to C_GetMechanismInfo, which may involve talking to a token/slot.
>>>>>>
>>>>>>
>>>>>>
>>>>>> These calls may be slow - especially if other programs are using the token or key storage mechanism (including software storage systems that need to have locks) - so it would seem like this should be an asynchronous call. It would also seem that my straw man proposal fails to distinguish the uses of a particular algorithm - for example, a key may only support verification, but not signatures. These sorts of scenario arises even if raw keying material is exposed and implementations are fully software, I believe, since there are still limitations on how a key may be used.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ultimately, this means that the current proposed synchronous API is likely insufficient.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Based on what was proposed in the strawman-now-draft, this would seem to imply that the error/exception for an invalid Algorithm would not be able to be raised until the first call to .processData on the CryptoStream.
>>>>>>
>>>>>>
>>>>>>
>>>>>> eg:
>>>>>>
>>>>>> try {
>>>>>>
>>>>>>   var stream = window.crypto.encrypt("RS256", key);
>>>>>>
>>>>>> } catch (err) {
>>>>>>
>>>>>>   if (err instanceof InvalidAlgorithmException) {
>>>>>>
>>>>>>     // "RS256" does not parse as a valid Algorithm
>>>>>>
>>>>>>   }
>>>>>>
>>>>>> }
>>>>>>
>>>>>> stream.onerror = function(err) {
>>>>>>
>>>>>>   if (err instanceof UnsupportedAlgorithmException) {
>>>>>>
>>>>>>     // "RS256" is parsed, but either the key or the underlying implementation doesn't support it.
>>>>>>
>>>>>>   }
>>>>>>
>>>>>> }
>>>>>>
>>>>>> // Until this is called, it's unknown whether or not "stream" will actually work. If it ends up failing, stream.onerror will be called.
>>>>>>
>>>>>> stream.processData(...);
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Note that none of the above semantics would necessarily be altered by a MUST-IMPLEMENT registry (ISSUE-1), since there would still need to be some form of error handling for invalid constants/strings and for unsupported key+algorithm+operation tuples.
>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Further, attempting to discover an algorithm by sending 'junk' data (constants or random) may result in user agents having to interact with the user, since there may be security concerns about even calling .processData() on an object (regardless of .complete()), which is some of what ISSUE-2 may be related to.
>>>>>>
>>>>>>
>>>>>>
>>>>>> As an implementer, the above semantics look both undesirable and limiting to potential consumers. How do others in the WG feel? Should there be an explicitly asynchronous call to determine whether or not an algorithm/algorithm+key pair/algorithm+key+operation tuple is supported, without requiring .processBytes()? Are there alternate proposals that would simplify or could replace the above API?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Ryan
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
Received on Saturday, 21 July 2012 00:38:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:11 UTC