RE: Issue 195: Certificate Management API

It appears that AlgorithmIdentifier does in some cases identify a complete ciphersuite, including both key generation and hash algorithms, and that some (but not all) the ciphersuites recommended by NIST are included.
For example, here is what Section 18.5.2 of WebCrypto (http://www.w3.org/TR/WebCryptoAPI/#algorithms) says:
18.5.2. For Implementers ¶<http://www.w3.org/TR/WebCryptoAPI/#algorithm-recommendations-implementers>
In order to promote interoperability for developers, this specification includes a list of suggested algorithms. These are considered to be the most widely used algorithms in practice at the time of writing, and therefore provide a good starting point for initial implementations of this specification. The suggested algorithms are:

  *   HMAC<http://www.w3.org/TR/WebCryptoAPI/#hmac> using SHA-1<http://www.w3.org/TR/WebCryptoAPI/#alg-sha-1>
  *   HMAC<http://www.w3.org/TR/WebCryptoAPI/#hmac> using SHA-256<http://www.w3.org/TR/WebCryptoAPI/#alg-sha-256>
  *   RSASSA-PKCS1-v1_5<http://www.w3.org/TR/WebCryptoAPI/#rsassa-pkcs1> using SHA-1<http://www.w3.org/TR/WebCryptoAPI/#alg-sha-256>
  *   RSA-PSS<http://www.w3.org/TR/WebCryptoAPI/#rsa-pss> using SHA-256<http://www.w3.org/TR/WebCryptoAPI/#alg-sha-256> and MGF1 with SHA-256<http://www.w3.org/TR/WebCryptoAPI/#alg-sha-256>.
  *   RSA-OAEP<http://www.w3.org/TR/WebCryptoAPI/#rsa-oaep> using SHA-256<http://www.w3.org/TR/WebCryptoAPI/#alg-sha-256> and MGF1 with SHA-256<http://www.w3.org/TR/WebCryptoAPI/#alg-sha-256>.
  *   ECDSA<http://www.w3.org/TR/WebCryptoAPI/#ecdsa> using P-256<http://www.w3.org/TR/WebCryptoAPI/#dfn-NamedCurve-p256> curve and SHA-256<http://www.w3.org/TR/WebCryptoAPI/#alg-sha-256>
  *   AES-CBC<http://www.w3.org/TR/WebCryptoAPI/#aes-cbc>

Since we are talking about DTLS certificates, NIST Special Publication 800-52 (see: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf) is relevant.  Table 3-1 includes the following recommendations:

[cid:image001.png@01D0F533.A7321980]

From: Roman Shpount [mailto:rshpount@turbobridge.com]
Sent: Tuesday, September 22, 2015 10:24 AM
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: public-ortc@w3.org
Subject: Re: Issue 195: Certificate Management API

Should we add optional parameter of type HashAlgorithmIdentifier (https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#dfn-HashAlgorithmIdentifier<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdvcs.w3.org%2fhg%2fwebcrypto-api%2fraw-file%2ftip%2fspec%2fOverview.html%23dfn-HashAlgorithmIdentifier&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c649571601c584caa6e2708d2c3729556%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=O0VcxxWePB7a1fKRt%2fFCi2yTtWDsNwa8QSpMKD2yhlI%3d>) to generateCertificate?

It seems strange that it is not there already.

_____________
Roman Shpount

On Tue, Sep 22, 2015 at 1:00 PM, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:
WebRTC 1.0 added an (optional) Certificate Management API in Section 5.5 in the last Editor’s draft.   This appears needed in ORTC API in order to solve the DtlsTransport forking problem.

So below find the proposed text to be inserted in Section 15.   Some oddities found in the API:


a.       keygenAlgorithm only specifies the algorithm used to generate the key – it does not specify the hash algorithm.  So if in future we needed to transition from SHA-256 to some other hash algorithm, it isn’t clear how that would happen.

b.      In practice, implementations are likely to use the certificate generation functionality in the underlying DTLS implementation (e.g. BoringSSL, OpenSSL, S-Channel, etc.).  So why the references to WebCrypto?