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 Tuesday, 17 July 2012 00:58:32 UTC