* utils: guard against zero-length int_to_bytes
* add tests for HBKDF with llen=0
* kbkdf: guard against llen==0
* test that kbkdf rejects llen==0 at __init__
* add standalone test for zero-length int_to_bytes
* Update src/cryptography/hazmat/primitives/kdf/kbkdf.py
typo
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
---------
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
* re-add branch we dropped in the past
* add the test
* test all key types
* Update src/rust/src/backend/utils.rs
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
---------
Co-authored-by: Alex Gaynor <alex.gaynor@gmail.com>
Empty string is a valid result from RFC4514 serialization, and should parse successfully.
According to https://datatracker.ietf.org/doc/html/rfc4514#section-2.1
> If the RDNSequence is an empty sequence, the result is the empty or zero-length string.
* verification: WIP client verification skeleton
Signed-off-by: William Woodruff <william@yossarian.net>
* verify: fill in build_client_verifier
Signed-off-by: William Woodruff <william@yossarian.net>
* implement ClientVerifier.verify
Signed-off-by: William Woodruff <william@yossarian.net>
* verification: make Python 3.8 happy
Signed-off-by: William Woodruff <william@yossarian.net>
* switch to a full VerifiedClient type
Signed-off-by: William Woodruff <william@yossarian.net>
* remove the SubjectOwner::None hack
Signed-off-by: William Woodruff <william@yossarian.net>
* docs: fix ClientVerifier
Signed-off-by: William Woodruff <william@yossarian.net>
* verification: replace match with if
Signed-off-by: William Woodruff <william@yossarian.net>
* return GNs directly, not whole extension
Signed-off-by: William Woodruff <william@yossarian.net>
* docs/verification: document UnsupportedGeneralNameType raise
Signed-off-by: William Woodruff <william@yossarian.net>
* lib: RFC822 checks on NCs
* test_limbo: enable client tests
* tests: flake
* test_verification: more Python API coverage
* verification: filter GNs by NC support
* verification: forbid unsupported NC GNs
This is what we should have been doing originally, per
RFC 5280 4.2.1.10:
> If a name constraints extension that is marked as critical
> imposes constraints on a particular name form, and an instance of
> that name form appears in the subject field or subjectAltName
> extension of a subsequent certificate, then the application MUST
> either process the constraint or reject the certificate.
* docs/verification: remove old sentence
Signed-off-by: William Woodruff <william@yossarian.net>
* verification: ensure the right EKU for client/server paths
Signed-off-by: William Woodruff <william@yossarian.net>
* test_limbo: fixup EKU assertion
* verification: feedback
---------
Signed-off-by: William Woodruff <william@yossarian.net>
* test_limbo: skip non-SERVER cases for now
Signed-off-by: William Woodruff <william@yossarian.net>
* Bump x509-limbo and/or wycheproof in CI
---------
Signed-off-by: William Woodruff <william@yossarian.net>
Co-authored-by: pyca-boringbot[bot] <pyca-boringbot[bot]+106132319@users.noreply.github.com>
* Fix ASN.1 for S/MIME capabilities.
The current implementation defines the SMIMECapabilities attribute
so that its value is a SEQUENCE of all the algorithm OIDs that are
supported.
However, the S/MIME v3 spec (RFC 2633) specifies that each algorithm
should be specified in its own SEQUENCE:
SMIMECapabilities ::= SEQUENCE OF SMIMECapability
SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL }
(RFC 2633, Appendix A)
This commit changes the implementation so that each algorithm
is inside its own SEQUENCE. This also matches the OpenSSL
implementation.
* Fix the RSA OID used for signing PKCS#7/SMIME
The current implementation computes the algorithm identifier used
in the `digest_encryption_algorithm` PKCS#7 field
(or `SignatureAlgorithmIdentifier` in S/MIME) based on both the
algorithm used to sign (e.g. RSA) and the digest algorithm (e.g. SHA512).
This is correct for ECDSA signatures, where the OIDs used include the
digest algorithm (e.g: ecdsa-with-SHA512). However, due to historical
reasons, when signing with RSA the OID specified should be the one
corresponding to just RSA ("1.2.840.113549.1.1.1" rsaEncryption),
rather than OIDs which also include the digest algorithm (such as
"1.2.840.113549.1.1.13", sha512WithRSAEncryption).
This means that the logic to compute the algorithm identifier is the
same except when signing with RSA, in which case the OID will always
be `rsaEncryption`. This is consistent with the OpenSSL implementation,
and the RFCs that define PKCS#7 and S/MIME.
See RFC 3851 (section 2.2), and RFC 3370 (section 3.2) for more details.
* Add tests for the changes in PKCS7 signing
* PKCS7 fixes from code review
* Update CHANGELOG
This PR supports a bad old algorithm to support a scapy use case, but
does not expose support for effective key bits or any key length other
than 128-bit. CBC support only -- no other modes.
