Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

document specs [skip ci] #190

Merged
merged 3 commits into from
Jun 28, 2023
Merged

document specs [skip ci] #190

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4189139
document specs [skip ci]
baentsch Jun 20, 2023
b04bebc
Update README.md
baentsch Jun 27, 2023
7e7a2f5
complete reference to standards implemented [skip ci]
baentsch Jun 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
30 changes: 30 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,36 @@ mechanism and X.509 data structures. Also available is support for
TLS1.3 signature functionality via the [OpenSSL3 fetchable signature
algorithm feature](https://github.com/openssl/openssl/pull/19312).

Standards implemented
---------------------

For non-post-quantum algorithms, this provider is basically silent, i.e.,
permits use of standards and algorithms implemented by [openssl](https://github.com/openssl/openssl)
, e.g., concerning X.509, PKCS#8 or CMS.

For post-quantum algorithms, the version of the cryptographic algorithm used
depends on the version of [liboqs](https://github.com/open-quantum-safe/liboqs) used.
Regarding the integration of post-quantum algorithms into higher level
components, this provider implements the following standards:

- For TLS:
- Hybrid post-quantum / traditional key exchange:
- The data structures used follow the Internet-Draft [Hybrid key exchange in TLS 1.3](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/), namely simple concatenation of traditional and post-quantum public keys and shared secrets.
- The algorithm identifiers used are documented in [oqs-kem-info.md](https://github.com/open-quantum-safe/oqs-provider/blob/main/oqs-template/oqs-kem-info.md).
- Hybrid post-quantum / traditional signatures in TLS:
- For public keys and digital signatures inside X.509 certificates, see the bullet point on X.509 below.
- For digital signatures outside X.509 certificates and in the TLS 1.3 handshake directly, the data structures used follow the same encoding format as that used for X.509 certificates, namely simple concatenation of traditional and post-quantum signatures.
- The algorithm identifiers used are documented in [oqs-sig-info.md](https://github.com/open-quantum-safe/oqs-provider/blob/main/oqs-template/oqs-sig-info.md).
- For X.509:
- Hybrid post-quantum / traditional public keys and signatures:
- The data structures used follow the Internet-Draft [Internet X.509 Public Key Infrastructure: Algorithm Identifiers for Dilithium](https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/), namely simple concatenation of traditional and post-quantum components in plain binary / OCTET_STRING representations.
- The algorithm identifiers (OIDs) used are documented in [oqs-sig-info.md](https://github.com/open-quantum-safe/oqs-provider/blob/main/oqs-template/oqs-sig-info.md).
- For PKCS#8:
- Hybrid post-quantum / traditional private keys:
- Simple concatenation of traditional and post-quantum components in plain binary / OCTET_STRING representations.

Additionally worthwhile noting is that only quantum-safe [signature algorithms](#signature-algorithms) are persisted via PKCS#8 and X.509. No corresponding encoder/decoder logic exists for quantum safe [KEM algorithms](#kem-algorithms) -- See also #194.

Algorithms
----------

Expand Down