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

Re: crypto-ISSUE-29 (block modes): Handling of block encryption modes and padding [Web Cryptography API]

From: Wan-Teh Chang <wtc@google.com>
Date: Fri, 24 Aug 2012 18:04:21 -0700
Message-ID: <CALTJjxHjs2UGYzYRCCtDK5UKHMdEsAcHLGXogfP2XUeFMrH=Tg@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>, "David McGrew (mcgrew)" <mcgrew@cisco.com>
Cc: Web Cryptography Working Group <public-webcrypto@w3.org>

Thank you for the info. I found the guidance you quoted in RFC 3447
for RSAES-OAEP and EMSA-PSS. The recommendation is repeated in RFC
4055 Section 3.1 for RSASSA-PSS keys:

   When signing, it is RECOMMENDED that the parameters, except for
   possibly saltLength, remain fixed for all usages of a given RSA key

I did not find similar language that recommends using a fixed hash
algorithm for a given signing key in X9.62-2005 and FIPS 186-3. Also,
RFC 5480 still uses the completely unrestricted id-ecPublicKey
algorithm identifier for ECDSA keys.

So it seems that these standards and RFCs, especially for ECDSA keys,
still allow key algorithms to be less restrictive/specific than crypto
operation algorithms. In PKCS #11, key algorithms and crypto operation
algorithms come from two namespaces -- CKK_xxx for key types and
CKM_xxx for mechanisms.

The implication is that this kind of "tainting" will need to be
maintained by the user agents, and it would be difficult to migrate
key  tainting from one computer to another for keys in smart cards
unless the smart cards themselves carry key tainting information.

Received on Saturday, 25 August 2012 01:04:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC