From 58d101b72189373fb9934f2ede2838ba37706dd6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Manuel=20P=C3=A9gouri=C3=A9-Gonnard?= Date: Thu, 10 Feb 2022 12:58:09 +0100 Subject: [PATCH 1/3] Fix a few more typos MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Manuel Pégourié-Gonnard --- docs/architecture/psa-migration/psa-limitations.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/architecture/psa-migration/psa-limitations.md b/docs/architecture/psa-migration/psa-limitations.md index c60eddc6f..915922d02 100644 --- a/docs/architecture/psa-migration/psa-limitations.md +++ b/docs/architecture/psa-migration/psa-limitations.md @@ -40,11 +40,11 @@ Arbitrary parameters for FFDH (See also the first paragraph in the previous section.) Currently, the PSA Crypto API can only perform FFDH with a limited set of -well-know parameters (some of them defined in the spec, but implementations +well-known parameters (some of them defined in the spec, but implementations are free to extend that set). TLS 1.2 (and earlier) on the other hand have the server send explicit -parameters (P and G) in is ServerKeyExchange message. This has been found to +parameters (P and G) in its ServerKeyExchange message. This has been found to be suboptimal for security, as it is prohibitively hard for the client to verify the strength of these parameters. This led to the development of RFC 7919 which allows use of named groups in TLS 1.2 - however as this is only an @@ -155,7 +155,7 @@ When it comes to cryptographic operations, only two things are supported: The verification is done using `mbedtls_pk_verify_ext()`. Note: since X.509 parsing ensures that message hash = encoding hash, and -`mbedtls_pk_verify_ext()` use encoding hash = mgf1 hash, it looks like all +`mbedtls_pk_verify_ext()` uses encoding hash = mgf1 hash, it looks like all three hash algorithms must be equal, which would be good news as it would match a limitation of the PSA API. From c7f325437990e8a7737bc2cec0f57cdce409f300 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Manuel=20P=C3=A9gouri=C3=A9-Gonnard?= Date: Thu, 10 Feb 2022 13:00:33 +0100 Subject: [PATCH 2/3] Clarify a sentence MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Manuel Pégourié-Gonnard --- docs/architecture/psa-migration/psa-limitations.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/architecture/psa-migration/psa-limitations.md b/docs/architecture/psa-migration/psa-limitations.md index 915922d02..45c78063f 100644 --- a/docs/architecture/psa-migration/psa-limitations.md +++ b/docs/architecture/psa-migration/psa-limitations.md @@ -53,8 +53,8 @@ extension. In TLS 1.3 the situation will be simpler: named groups are the only option, so the current PSA Crypto API is a good match for that. (Not -coincidentally, the groups used by RFC 7919 and TLS 1.3 are part those defined -in the specification.) +coincidentally, all the groups used by RFC 7919 and TLS 1.3 are included +in the PSA specification.) There are several options here: From c70013e4bc92fb449f6b04416fdfc7fdcad676aa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Manuel=20P=C3=A9gouri=C3=A9-Gonnard?= Date: Thu, 10 Feb 2022 13:07:22 +0100 Subject: [PATCH 3/3] Clarify the trailer field situation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Manuel Pégourié-Gonnard --- docs/architecture/psa-migration/psa-limitations.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/architecture/psa-migration/psa-limitations.md b/docs/architecture/psa-migration/psa-limitations.md index 45c78063f..a7c4afb9f 100644 --- a/docs/architecture/psa-migration/psa-limitations.md +++ b/docs/architecture/psa-migration/psa-limitations.md @@ -83,7 +83,8 @@ the hash algorithm potentially used to hash the message being signed: - a mask generation function - most commonly MGF1, which in turn is parametrized by a hash algorithm - a salt length -- a trailer field - this is universally 0xBC as far as I've seen +- a trailer field - the value is fixed to 0xBC by PKCS#1 v2.1, but was left + configurable in the original scheme; 0xBC is used everywhere in pratice. Both the existing `mbedtls_` API and the PSA API support only MGF1 as the generation function (and only 0xBC as the trailer field), but there are