GithubStar/UA-.NETStandard
1
0
Fork 0
mirror of https://github.com/OPCFoundation/UA-.NETStandard.git synced 2026-10-27 21:55:54 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
master
UA-.NETStandard/docs/EccProfiles.md
T
Marc SchierRoman EttlingerClaude Opus 5.5
 5899354441 Clarify documentation, migration guidance, and SDK selection (#4823) 
# Description

Remove stock phrasing and correct misleading or inconsistent technical
documentation. The initial two passes covered 367 Markdown files,
followed by an interactive review of 169 editorial flags. The U5
interpretation originally deferred in that review has since received the
upstream Mantis answer recorded by #4843; remaining server/spec
follow-ups stay explicit in the CTT log.

- Correct package responsibilities, migration steps, API names,
ownership, protocol descriptions and links. Keep bundled migration
guides synchronized. Preserve historical conclusions as historical
records with separate re-check notes.
- Provide at least two rendered TOC levels throughout `docs/`. Convert
appropriate architecture figures to Mermaid without changing code
examples, transcripts or historical quotations.
- Address the October 19 feedback with concrete setup/migration
instructions, corrected certificate paths and PubSub names, shorter
repeated caveats, consistent XML comments, and a full review of the
Concepts guide. Retain #4839's API corrections.
- Integrate #4841's runtime/performance guidance and review
incoming/recent prose. Preserve dated measurements rather than claiming
new benchmark runs; clarify allocation ratios, startup-only processor
settings, JIT warm-up and the benchmark commit's scope. Missing raw
measurement artifacts and repeat ranges remain tracked by #4842.
- Merge master through `e8c5d800a` in `32c6394b7`. Resolve the CTT log
conflict using the updated Mantis states and OPC answers, retaining
historical framing and re-checks for C28/C32/C43.
- Address the latest naming/index feedback in `adb5bf693`: rename the
guides to `docs/WotCon.md` and `docs/WotNodeSetConversion.md`; move the
provider and DataType-declaration contracts into the conversion guide
and remove `docs/WoT.md`. Rename `samples/DI` to `samples/Di` and
`samples/Isa95` to `samples/ISA95`. Add content-index READMEs to Di,
FluentApi, ISA95, Lds and PubSub; update solution entries, project
references, Docker/CI paths, test fixture paths and documentation links
with exact casing.

**WoT guide scope.** This branch retains the detailed conversion guide
that #4758 had replaced with an anchor stub. Conversion limits, verified
document sets, preservation rules and provider ownership now live
together in `WotNodeSetConversion.md`; binding/runtime guidance remains
in `WotBindings.md` and `WotCon.md`. The design-rationale/test-ledger
prose was shortened, the oversized argument-table cell moved into its
section, and existing anchors preserved.

**SDK policy is a separate, explicit user-directed change.**
`global.json` sets a stable minimum of `10.0.400`, `rollForward:
latestMajor`, and `allowPrerelease: false`. Newer major SDKs are
permitted; CI's explicit SDK pins are unchanged. README, GettingStarted,
DeveloperGuide and Recycling instructions reflect the possible analyzer
differences. The image-contract regression fix accepts compatible stable
SDK images instead of requiring exact equality with the floor.

The latest four rename/index threads are resolved after publication.
Three older threads remain open: universal obsolete-removal timing,
unconditional nonce-strength wording, and a blanket Vision NativeAOT
claim. Existing implementation/evidence constraints are explained in
their inline replies. The two-level TOCs remain as requested.

## Validation

- `git diff --check` and staged diff checks: passed. The untouched
upstream AutoID NodeSet retains its provenance bytes, including two
existing license-header trailing spaces.
- `.\.azurepipelines\validate-migration-plugin.ps1`: passed; 15 bundled
migration documents and manifests synchronized.
- Documentation/path validation: **101** documents retain two rendered
TOC levels (**2,228** entries), with idempotent formatting. **52** new
relative links and their anchors passed exact-case checks. No tracked
references to the old guide/sample paths remain. Both relocated
provider-contract sections are preserved in the destination.
- `dotnet sln UA.slnx list`: passed; shows the renamed Di/ISA95 projects
and the existing FluentApi/Lds/PubSub projects. Updated solution and
pump ProjectReference paths also passed exact-case existence checks.
- Latest focused commands, run from the repository root:

```powershell
# Passed: 61 channel send-order and reconnect tests.
dotnet test tests\Opc.Ua.Core.Tests\Opc.Ua.Core.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~UaSCBinaryChannelSendOrderTests|FullyQualifiedName~TcpReconnectKeyAgreementTests' --verbosity minimal

# Passed: 5 pump datasheet tests; builds the renamed pump sample.
dotnet test tests\Opc.Ua.Di.Tests\Opc.Ua.Di.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~PumpDatasheetConformanceTests' --verbosity minimal

# Passed: 4 repository NodeSet path/round-trip tests, including the moved pump models.
dotnet test tests\Opc.Ua.Types.Tests\Opc.Ua.Types.Tests.csproj -p:CustomTestTarget=net10.0 --filter 'FullyQualifiedName~RepositorySourceSurvivesSerializedLinkedPartitionsAsync' --verbosity minimal

# Passed: build, zero warnings/errors.
dotnet build samples\ISA95\MinimalIsa95Server\MinimalIsa95Server.csproj -p:CustomTestTarget=net10.0 -f net10.0 --verbosity minimal

# Passed: dependent sample-test project build, zero warnings/errors.
dotnet build tests\Opc.Ua.WotCon.Samples.Tests\Opc.Ua.WotCon.Samples.Tests.csproj -p:CustomTestTarget=net10.0 -f net10.0 --verbosity minimal
```

Earlier focused integration checks passed 2,620 tests across AutoID,
event queues/scheduling, source generation, MCP/package profiles and
WoT. Both reviewed Mermaid diagrams rendered locally without network
access. These checks are not a full solution run.

The full solution has **not** been rerun for this review. Earlier
`dotnet test UA.slnx -p:CustomTestTarget=net10.0 --verbosity quiet` did
not pass: three AOT projects rejected VSTest and 20 Vision tests failed
during graphics initialization with `OutOfMemoryException`. Remaining
long-running tests were stopped at the user's request. A focused Vision
rerun passed 558 tests and reproduced those 20 failures. The earlier
`dotnet test UA.slnx -p:CustomTestTarget=net48 --verbosity quiet` was
blocked by the former SDK pin and was not retried after the policy
change. The user approved proceeding with those limitations documented;
current remote CI is not claimed green.

## Related Issues

- Follow-up #4842 tracks the requested 2.0.2+ benchmark/tuning and
diagnostic-tool documentation refresh. #4841 supplies documentation and
earlier results, not all newly requested measurements.
- #4758 explains the conversion guide's earlier consolidation; the
current provider contracts are now consolidated into
`WotNodeSetConversion.md`.
- #4839 supplies the reviewed API corrections; #4843 supplies the
updated CTT issue record.
- The original prose cleanup and SDK policy were user-requested without
a source issue. No new runtime architecture is introduced by these
documentation edits.

## Checklist

_Put an `x` in the boxes that apply. You can complete these step by step
after opening the PR._

- [ ] I have signed the
[CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf)
and read the
[CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md)
doc.
- [ ] I have added tests that prove my fix is effective or that my
feature works and increased code coverage.
- [x] I have added all necessary documentation.
- [ ] I have verified that my changes do not introduce (new) build or
analyzer warnings.
- [ ] I ran **all** tests locally using the **UA.slnx** solution against
at least .net **framework** and .net **10**, and all passed.
- [ ] I fixed **all** failing and flaky tests in the CI pipelines and
**all** CodeQL warnings.
- [ ] I have addressed **all** PR feedback received.

---------

Co-authored-by: Roman Ettlinger <romanett98@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-21 10:10:55 +02:00

335 lines
18 KiB
Markdown
Raw Permalink Blame History

# Support for Elliptic Curve Cryptography (ECC) Certificates in Server and Client Applications
Server and client applications support encrypted communication with RSA
and elliptic curve cryptography (ECC) certificates. This guide explains
how to configure both certificate types.
## Contents
- [Support for Elliptic Curve Cryptography (ECC) Certificates in Server and Client Applications](#support-for-elliptic-curve-cryptography-ecc-certificates-in-server-and-client-applications)
- [Previous Client and Server application configuration supports only RSA certificates](#previous-client-and-server-application-configuration-supports-only-rsa-certificates)
- [Previous Server application configuration supports only RSA certificates](#previous-server-application-configuration-supports-only-rsa-certificates)
- [New Client and Server application configuration support both RSA and ECC certificates](#new-client-and-server-application-configuration-support-both-rsa-and-ecc-certificates)
- [New Server application configuration related to ECC certificates](#new-server-application-configuration-related-to-ecc-certificates)
- ["Old" Client and Server application configuration format VS "New" Client and Server application configuration format](#old-client-and-server-application-configuration-format-vs-new-client-and-server-application-configuration-format)
- [Configure GDS for use with ECC Certificates](#configure-gds-for-use-with-ecc-certificates)
- [Known Limitations](#known-limitations)
The [previous configuration](#previous-client-and-server-application-configuration-supports-only-rsa-certificates)
supports RSA certificates. The
[new configuration](#new-client-and-server-application-configuration-support-both-rsa-and-ecc-certificates)
supports both RSA and ECC certificates. The guide also describes
compatibility and ECC limitations.
## Previous Client and Server application configuration supports only RSA certificates
Up to now, the configuration supported encrypted communication using only the RSA encryption algorithm. That means that the server and client certificates were RSA certificates and there was just one RSA certificate per application needed to be configured.
The XML tag which contained the RSA certificate to be configured was `<ApplicationCertificate>`. This tag is still used for the RSA certificate configuration in backward compatibility mode as further described below:
```xml
<!-- The security configuration for the server. -->
<SecurityConfiguration>
<!-- Where the application instance certificate is stored (MachineDefault) -->
<ApplicationCertificate>
<StoreType>Directory</StoreType>
<StorePath>%LocalApplicationData%/OPC Foundation/pki/own</StorePath>
<SubjectName>CN=Quickstart Reference Server, C=US, S=Arizona, O=OPC Foundation, DC=localhost</SubjectName>
</ApplicationCertificate>
....
</SecurityConfiguration>
```
## Previous Server application configuration supports only RSA certificates
For Server applications the configuration of the RSA certificate involves also specifying the SecurityPolicies to be supported by the server:
```xml
<!-- The security configuration for the server. -->
<SecurityConfiguration>
<!-- The security policy to use. -->
<SecurityPolicies>
<ServerSecurityPolicy>
<SecurityMode>SignAndEncrypt_3</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>None_1</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#None</SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>Sign_2</SecurityMode>
<SecurityPolicyUri></SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>SignAndEncrypt_3</SecurityMode>
<SecurityPolicyUri></SecurityPolicyUri>
</ServerSecurityPolicy>
....
</SecurityConfiguration>
```
## New Client and Server application configuration support both RSA and ECC certificates
With the newly introduced support for ECC certificates, the configuration of the server application has been extended to support both RSA and ECC certificates. The XML tag under which both the RSA and ECC certificates are configured is `<ApplicationCertificates>`.
The `<ApplicationCertificate>` tag is still used for the RSA certificate configuration in backward compatibility mode, meaning that old server configurations are still supported, but they cannot simultaneously coexist.
The new configuration of the server application is described below:
```xml
<!-- The security configuration for the server. -->
<SecurityConfiguration>
<!-- Where the application instance certificate is stored (MachineDefault) -->
<ApplicationCertificates>
<CertificateIdentifier>
<StoreType>Directory</StoreType>
<StorePath>%LocalApplicationData%/OPC Foundation/pki/own</StorePath>
<SubjectName>CN=Quickstart Reference Server, C=US, S=Arizona, O=OPC Foundation, DC=localhost</SubjectName>
<CertificateTypeString>RsaSha256</CertificateTypeString>
</CertificateIdentifier>
<CertificateIdentifier>
<!-- <TypeId>NistP256</TypeId> -->
<StoreType>Directory</StoreType>
<StorePath>%LocalApplicationData%/OPC Foundation/pki/own</StorePath>
<SubjectName>CN=Quickstart Reference Server, C=US, S=Arizona, O=OPC Foundation, DC=localhost</SubjectName>
<CertificateTypeString>NistP256</CertificateTypeString>
</CertificateIdentifier>
<CertificateIdentifier>
<!-- <TypeId>NistP384</TypeId> -->
<StoreType>Directory</StoreType>
<StorePath>%LocalApplicationData%/OPC Foundation/pki/own</StorePath>
<SubjectName>CN=Quickstart Reference Server, C=US, S=Arizona, O=OPC Foundation, DC=localhost</SubjectName>
<CertificateTypeString>NistP384</CertificateTypeString>
</CertificateIdentifier>
<CertificateIdentifier>
<!-- <TypeId>BrainpoolP256r1</TypeId> -->
<StoreType>Directory</StoreType>
<StorePath>%LocalApplicationData%/OPC Foundation/pki/own</StorePath>
<SubjectName>CN=Quickstart Reference Server, C=US, S=Arizona, O=OPC Foundation, DC=localhost</SubjectName>
<CertificateTypeString>BrainpoolP256r1</CertificateTypeString>
</CertificateIdentifier>
<CertificateIdentifier>
<!-- <TypeId>BrainpoolP384r1</TypeId> -->
<StoreType>Directory</StoreType>
<StorePath>%LocalApplicationData%/OPC Foundation/pki/own</StorePath>
<SubjectName>CN=Quickstart Reference Server, C=US, S=Arizona, O=OPC Foundation, DC=localhost</SubjectName>
<CertificateTypeString>BrainpoolP384r1</CertificateTypeString>
</CertificateIdentifier>
</ApplicationCertificates>
....
</SecurityConfiguration>
```
This layout of the configuration file allows the server to support both RSA and ECC certificates and allows the server to generate certificates of different types. The `<CertificateTypeString>` tag is used to specify the type of the certificate.
The supported types are:
- `RsaSha256` for RSA certificates
- `NistP256` for ECC certificates with NIST P256 curve
- `NistP384` for ECC certificates with NIST P384 curve
- `BrainpoolP256r1` for ECC certificates with Brainpool P256r1 curve
- `BrainpoolP384r1` for ECC certificates with Brainpool P384r1 curve
Additionally, this layout enables the user to select a specific `<SubjectName>` for each certificate. This is useful when the user wants to generate certificates with different `<SubjectName>`s.
## New Server application configuration related to ECC certificates
The Server applications can configure the supported SecurityPolicies in the same way as before, but now the SecurityPolicies can be configured for each ECC specific SecurityPolicyUri which is to be supported by the server:
```xml
<!-- The security configuration for the server. -->
<SecurityConfiguration>
<!-- The security policy to use. -->
<SecurityPolicies>
<ServerSecurityPolicy>
<SecurityMode>SignAndEncrypt_3</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>Sign_2</SecurityMode>
<SecurityPolicyUri></SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>SignAndEncrypt_3</SecurityMode>
<SecurityPolicyUri></SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>Sign_2</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#ECC_nistP256</SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>Sign_2</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#ECC_nistP384</SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>Sign_2</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#ECC_brainpoolP256r1</SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>Sign_2</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#ECC_brainpoolP384r1</SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>SignAndEncrypt_3</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#ECC_nistP256</SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>SignAndEncrypt_3</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#ECC_nistP384</SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>SignAndEncrypt_3</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#ECC_brainpoolP256r1<SecurityPolicyUri>
</ServerSecurityPolicy>
<ServerSecurityPolicy>
<SecurityMode>SignAndEncrypt_3</SecurityMode>
<SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#ECC_brainpoolP384r1</SecurityPolicyUri>
</ServerSecurityPolicy>
</SecurityPolicies>
....
</SecurityConfiguration>
```
With the introduction of ECC certificates, the `<SecurityPolicies>` section of the configuration file has been extended to support ECC specific SecurityPolicies. The ECC specific SecurityPolicies are the following:
- `http://opcfoundation.org/UA/SecurityPolicy#ECC_nistP256`
- `http://opcfoundation.org/UA/SecurityPolicy#ECC_nistP384`
- `http://opcfoundation.org/UA/SecurityPolicy#ECC_brainpoolP256r1`
- `http://opcfoundation.org/UA/SecurityPolicy#ECC_brainpoolP384r1`
For every ECC-specific policy in `<SecurityPolicies>`, the server must have
a corresponding ECC certificate in `<ApplicationCertificates>`. Its
`CertificateTypeString` must match the policy's curve. If a corresponding
certificate is missing, the server cannot start.
The server encrypts each `UserIdentityToken` with the certificate selected
by the active security policy or by the `<SecurityPolicyUri>` in its
`<UserTokenPolicy>`. To explicitly list the policies supported for user
identity tokens, configure them in `<UserTokenPolicies>`. They must also
appear in `<SecurityPolicies>`.
The following example shows how the server can specify the supported `<SecurityPolicy>`s for the UserIdentityTokens:
```xml
<!-- The SDK expects the server to support the same set of user tokens for every endpoint. -->
<UserTokenPolicies>
<!-- Allows anonymous users -->
<ua:UserTokenPolicy>
<ua:TokenType>Anonymous_0</ua:TokenType>
<!-- <ua:SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#None</ua:SecurityPolicyUri> -->
</ua:UserTokenPolicy>
<!-- Allows username/password with password encrypted using the active security policy-->
<ua:UserTokenPolicy>
<ua:TokenType>UserName_1</ua:TokenType>
<!-- passwords must be encrypted - this specifies what algorithm to use -->
<!-- if no algorithm is specified, the active security policy is used -->
<!-- <ua:SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</ua:SecurityPolicyUri> -->
</ua:UserTokenPolicy>
<!-- Allows username/password with password encrypted using ECC security-->
<ua:UserTokenPolicy>
<ua:TokenType>UserName_1</ua:TokenType>
<!-- passwords must be encrypted - this specifies what algorithm to use -->
<!-- if no algorithm is specified, the active security policy is used -->
<ua:SecurityPolicyUri>http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256</ua:SecurityPolicyUri>
</ua:UserTokenPolicy>
</UserTokenPolicies>
```
You can omit `<SecurityPolicyUri>` from `<UserTokenPolicy>`. In that case,
the server uses the active security policy to encrypt the
`UserIdentityToken`. Therefore, each policy listed in `<UserTokenPolicies>`
must also appear in `<SecurityPolicies>`.
If `<UserTokenPolicies>` names a policy that `<SecurityPolicies>` does not
include, the configuration is invalid.
## "Old" Client and Server application configuration format VS "New" Client and Server application configuration format
Applications using the old configuration continue to use RSA certificates
configured with `<ApplicationCertificate>`. The server must not list ECC
policies in `<SecurityPolicies>`. These applications cannot communicate with
peers that require ECC certificates.
Applications using the new configuration can support both RSA and ECC
certificates. Configure both certificate types with
`<ApplicationCertificates>`, then list the supported policies in
`<SecurityPolicies>`, including any ECC policies.
Use `<UserTokenPolicies>` to configure the policies used to encrypt user
identity tokens. These policies must also appear in `<SecurityPolicies>`.
Do not combine the old and new configuration formats. A configuration file
cannot contain both `<ApplicationCertificate>` and
`<ApplicationCertificates>`.
## Configure GDS for use with ECC Certificates
To use ECC certificates with the Global Discovery Server (GDS), update its
configuration as shown below.
```xml
<Extensions>
<ua:XmlElement>
<GlobalDiscoveryServerConfiguration xmlns="http://opcfoundation.org/UA/GDS/Configuration.xsd">
<CertificateGroups>
<CertificateGroupConfiguration>
<Id>Default</Id>
<CertificateType>RsaSha256ApplicationCertificateType</CertificateType>
```
Replace the `<CertificateType>` node of the Default CertificateGroupConfiguration with the `<CertificateTypes>` node.
This allows the Certificate Group to have multiple CA Certificates for the different Certificate types.
```xml
<Extensions>
<ua:XmlElement>
<GlobalDiscoveryServerConfiguration xmlns="http://opcfoundation.org/UA/GDS/Configuration.xsd">
<CertificateGroups>
<CertificateGroupConfiguration>
<Id>Default</Id>
<CertificateTypes>
<ua:String>RsaSha256ApplicationCertificateType</ua:String>
<ua:String>EccNistP256ApplicationCertificateType</ua:String>
<ua:String>EccNistP384ApplicationCertificateType</ua:String>
</CertificateTypes>
```
The old Configuration format is still supported but only supports either RSA or ECC Certificates for a single CertificateGroup.
The GDS checks on startup if a valid configuration was supplied.
## Known Limitations
Not all curves are supported by all OS platforms and not all .NET implementations offer cryptographic API support for all curve types.
**On .NET Framework 4.8 the ECDH agreement and the AEAD ciphers run in BouncyCastle.**
OPC UA Part 6 feeds the raw ECDH shared secret into HKDF. .NET Framework
only offers `ECDiffieHellman.DeriveKeyMaterial`, which hashes the secret
first, so the .NET Framework 4.8 build computes the raw agreement with the
managed `BouncyCastle.Cryptography` implementation (`ECDHBasicAgreement`),
which `Opc.Ua.Security.Certificates` already references on that target.
The ephemeral keys, ECDSA signatures and HKDF stay on the platform (CNG)
providers; only the agreement step is managed code. The AES-GCM and
ChaCha20-Poly1305 variants of the ECC policies (`ECC_*_AesGcm`,
`ECC_*_ChaChaPoly`) and `RSA_DH_AesGcm` / `RSA_DH_ChaChaPoly` need
authenticated ciphers that .NET Framework does not have, so on that target
the stack runs AES-GCM (`GcmBlockCipher` over `AesEngine`) and
ChaCha20-Poly1305 in BouncyCastle as well, also for the encrypted ECC user
tokens. Deployments bound to FIPS-validated or other certified cryptographic
modules should note that these steps are not performed by a validated module
on .NET Framework, so `CryptoCompliancePolicy.FipsOnly` withholds the ECC and
AEAD policies there, and that the managed AES is neither hardware accelerated
nor hardened against cache-timing side channels like the CNG implementation;
use the .NET 8+ build, or an RSA policy, where that matters. The .NET 8+
builds use `ECDiffieHellman.DeriveRawSecretAgreement`, `AesGcm` and
`ChaCha20Poly1305` from the BCL and do not load BouncyCastle for them.
All ECC policies (`ECC_nistP256`, `ECC_nistP384`, `ECC_brainpoolP256r1`,
`ECC_brainpoolP384r1` and their `_AesGcm` / `_ChaChaPoly` variants) are
available on every target, subject to the OS supporting the curve.
ECC certificate parsing and signing remain subject to OS curve support.
The supported ECC curve types are the following:
- `NistP256` for ECC certificates with NIST P256 curve
- `NistP384` for ECC certificates with NIST P384 curve
- `BrainpoolP256r1` for ECC certificates with Brainpool P256r1 curve
- `BrainpoolP384r1` for ECC certificates with Brainpool P384r1 curve
Reference in New Issue View Git Blame Copy Permalink