From 4592ed3a7f97c25fbd273de8a073d8c326341909 Mon Sep 17 00:00:00 2001 From: Neil Horman Date: Tue, 23 Apr 2024 04:17:40 -0400 Subject: [PATCH 1/7] Add a policy for migration of algorithms to the legacy provider --- policies/legacy-migration.md | 39 ++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 policies/legacy-migration.md diff --git a/policies/legacy-migration.md b/policies/legacy-migration.md new file mode 100644 index 0000000..a812f1f --- /dev/null +++ b/policies/legacy-migration.md @@ -0,0 +1,39 @@ +# Legacy Provider Policy +## Purpose +The Legacy Provider exists to create an opt-in availability mechanism for +algorithms that, for various reasons, should have their use discouraged. These +reasons include, but are not limited to: +* Discovered security issues leaving the algorithm in question unsafe for + general use +* Lack of popular use (i.e. balancing code size vs consumption frequency) + +OpenSSL recognizes that consumption of these algorithms may continue to be +required by consuming applications after the conditions above have been +recognized. The Legacy provider exists to provide a mechanism for such +applications to continue to access these algorithms while allowing applications +that don't require them to inadvertently continue to use them. + +## Constraints on moving an algorithm to the legacy provider +1) Migration of an algorithm to the legacy provider must occur on a semantically +versioned major release boundary. Once a major release includes a given +algorithm in a given provider, it must remain there for every minor release in +that major stream + +2) Prior to migration, the migration must be announced for at least 1 +semantically versioned patch level release (see announcement mechanism below) + +3) Coincidental to the announcement above, the algorithm in question may be made +available in both the source provider and the legacy provider. + +## Promotion of algorithms in the legacy provider to the default provider +Should the need arise, legacy provider algorithms may be promoted to the default +provider at any time. Removal from the Legacy provider should occur only on +semantically versioned major release boundaries. + +## Migration announcement mechanism +Announcements of migrations from a source provider to the Legacy provider is +made via the ALG-DEPRECATIONS.md file in the source code root directory for +OpenSSL. This file will list the algorithm SN, NID, the date at which the +deprecation was announced, and the date at which the algorithm was removed from +the source provider + From d24a1678e29e478090a9fa7ea53f5516e5815882 Mon Sep 17 00:00:00 2001 From: Neil Horman Date: Tue, 23 Apr 2024 11:16:13 -0400 Subject: [PATCH 2/7] fixup! Add a policy for migration of algorithms to the legacy provider --- policies/legacy-migration.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/policies/legacy-migration.md b/policies/legacy-migration.md index a812f1f..41f2f0a 100644 --- a/policies/legacy-migration.md +++ b/policies/legacy-migration.md @@ -1,19 +1,23 @@ # Legacy Provider Policy + ## Purpose The Legacy Provider exists to create an opt-in availability mechanism for algorithms that, for various reasons, should have their use discouraged. These reasons include, but are not limited to: + * Discovered security issues leaving the algorithm in question unsafe for general use + * Lack of popular use (i.e. balancing code size vs consumption frequency) OpenSSL recognizes that consumption of these algorithms may continue to be required by consuming applications after the conditions above have been recognized. The Legacy provider exists to provide a mechanism for such -applications to continue to access these algorithms while allowing applications -that don't require them to inadvertently continue to use them. +applications to continue having access to these algorithms while preventing +applications that don't require them from inadvertently using them. ## Constraints on moving an algorithm to the legacy provider + 1) Migration of an algorithm to the legacy provider must occur on a semantically versioned major release boundary. Once a major release includes a given algorithm in a given provider, it must remain there for every minor release in @@ -31,9 +35,8 @@ provider at any time. Removal from the Legacy provider should occur only on semantically versioned major release boundaries. ## Migration announcement mechanism -Announcements of migrations from a source provider to the Legacy provider is -made via the ALG-DEPRECATIONS.md file in the source code root directory for -OpenSSL. This file will list the algorithm SN, NID, the date at which the -deprecation was announced, and the date at which the algorithm was removed from -the source provider - +Announcements of migrations from the default provider to the Legacy provider is +made via the DEPRECATIONS.md file in the source code root directory for +OpenSSL. This file will list the algorithm SN, NID, the version in which the +deprecation was announced, and the version in which the algorithm was removed +from the source provider From 3e03520e14b13b197690ba1a76f25cedb836650e Mon Sep 17 00:00:00 2001 From: Neil Horman Date: Tue, 23 Apr 2024 12:37:50 -0400 Subject: [PATCH 3/7] fixup! Add a policy for migration of algorithms to the legacy provider --- policies/legacy-migration.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/policies/legacy-migration.md b/policies/legacy-migration.md index 41f2f0a..a3fc29f 100644 --- a/policies/legacy-migration.md +++ b/policies/legacy-migration.md @@ -21,10 +21,10 @@ applications that don't require them from inadvertently using them. 1) Migration of an algorithm to the legacy provider must occur on a semantically versioned major release boundary. Once a major release includes a given algorithm in a given provider, it must remain there for every minor release in -that major stream +that major stream. 2) Prior to migration, the migration must be announced for at least 1 -semantically versioned patch level release (see announcement mechanism below) +semantically versioned minor release (see announcement mechanism below). 3) Coincidental to the announcement above, the algorithm in question may be made available in both the source provider and the legacy provider. @@ -38,5 +38,5 @@ semantically versioned major release boundaries. Announcements of migrations from the default provider to the Legacy provider is made via the DEPRECATIONS.md file in the source code root directory for OpenSSL. This file will list the algorithm SN, NID, the version in which the -deprecation was announced, and the version in which the algorithm was removed -from the source provider +deprecation was announced, and the version in which the algorithm is to be +removed from the default provider. From 162d337385379ba8dcc05b48223f06a20c227b6d Mon Sep 17 00:00:00 2001 From: Neil Horman Date: Thu, 3 Oct 2024 08:48:05 -0400 Subject: [PATCH 4/7] Update policies/legacy-migration.md Co-authored-by: Richard Levitte --- policies/legacy-migration.md | 1 + 1 file changed, 1 insertion(+) diff --git a/policies/legacy-migration.md b/policies/legacy-migration.md index a3fc29f..03a69c8 100644 --- a/policies/legacy-migration.md +++ b/policies/legacy-migration.md @@ -30,6 +30,7 @@ semantically versioned minor release (see announcement mechanism below). available in both the source provider and the legacy provider. ## Promotion of algorithms in the legacy provider to the default provider + Should the need arise, legacy provider algorithms may be promoted to the default provider at any time. Removal from the Legacy provider should occur only on semantically versioned major release boundaries. From 7805f50389adab989d9d375c6a8cc9b1ff176fe5 Mon Sep 17 00:00:00 2001 From: Neil Horman Date: Thu, 3 Oct 2024 08:52:35 -0400 Subject: [PATCH 5/7] Update policies/legacy-migration.md Co-authored-by: Richard Levitte --- policies/legacy-migration.md | 1 + 1 file changed, 1 insertion(+) diff --git a/policies/legacy-migration.md b/policies/legacy-migration.md index 03a69c8..fe334d8 100644 --- a/policies/legacy-migration.md +++ b/policies/legacy-migration.md @@ -36,6 +36,7 @@ provider at any time. Removal from the Legacy provider should occur only on semantically versioned major release boundaries. ## Migration announcement mechanism + Announcements of migrations from the default provider to the Legacy provider is made via the DEPRECATIONS.md file in the source code root directory for OpenSSL. This file will list the algorithm SN, NID, the version in which the From ca136c9a471324be2d3f158f18c51d7cb56ce51b Mon Sep 17 00:00:00 2001 From: Neil Horman Date: Thu, 3 Oct 2024 08:56:07 -0400 Subject: [PATCH 6/7] Fixing up syntax nits --- policies/legacy-migration.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/policies/legacy-migration.md b/policies/legacy-migration.md index fe334d8..d81533f 100644 --- a/policies/legacy-migration.md +++ b/policies/legacy-migration.md @@ -18,13 +18,12 @@ applications that don't require them from inadvertently using them. ## Constraints on moving an algorithm to the legacy provider -1) Migration of an algorithm to the legacy provider must occur on a semantically -versioned major release boundary. Once a major release includes a given -algorithm in a given provider, it must remain there for every minor release in -that major stream. +1) Migration of an algorithm to the legacy provider must occur on a major +release boundary. Once a major release includes a given algorithm in a given +provider, it must remain there for every minor release in that major stream. -2) Prior to migration, the migration must be announced for at least 1 -semantically versioned minor release (see announcement mechanism below). +2) Prior to migration, the migration must be announced for at least one +minor release (see announcement mechanism below). 3) Coincidental to the announcement above, the algorithm in question may be made available in both the source provider and the legacy provider. @@ -33,12 +32,14 @@ available in both the source provider and the legacy provider. Should the need arise, legacy provider algorithms may be promoted to the default provider at any time. Removal from the Legacy provider should occur only on -semantically versioned major release boundaries. +major release boundaries. ## Migration announcement mechanism -Announcements of migrations from the default provider to the Legacy provider is -made via the DEPRECATIONS.md file in the source code root directory for +Announcements of migrations from a source provider to the Legacy provider is +made via the DEPRECATIONS.md file in the source code root directory for OpenSSL. This file will list the algorithm SN, NID, the version in which the deprecation was announced, and the version in which the algorithm is to be -removed from the default provider. +removed from the source provider. Note that deprecations may also be announced +in the release notes. + From 249d22902cd37e2d9eb0898dc1f7358c8cc8e4bb Mon Sep 17 00:00:00 2001 From: Neil Horman Date: Thu, 3 Oct 2024 08:57:49 -0400 Subject: [PATCH 7/7] Fixing NID comment --- policies/legacy-migration.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/policies/legacy-migration.md b/policies/legacy-migration.md index d81533f..ae79058 100644 --- a/policies/legacy-migration.md +++ b/policies/legacy-migration.md @@ -38,8 +38,9 @@ major release boundaries. Announcements of migrations from a source provider to the Legacy provider is made via the DEPRECATIONS.md file in the source code root directory for -OpenSSL. This file will list the algorithm SN, NID, the version in which the -deprecation was announced, and the version in which the algorithm is to be -removed from the source provider. Note that deprecations may also be announced -in the release notes. +OpenSSL. This file will list all the identities of the algorithm (names, +possible OIDs, possible NIDs), the version in which the deprecation was +announced, and the version in which the algorithm is to be removed from the +source provider. Note that deprecations may also be announced in the release +notes.