Age | Commit message (Collapse) | Author |
|
|
|
Used defenitions from PKIX1Explicit88 to avoid most
of the overcomplicated InformationalFrameWork (and friends) ASN-1 specs.
We want to keep the public_key API as small and simple as possible.
|
|
|
|
First attempt to add PKCS-7 does not compile
|
|
* ia/public_key/ssh_decode-comment-issue/OTP-9361:
public_key: ssh_decode now handles comments, at the end of the line, containing withespaces correctly
|
|
|
|
containing withespaces correctly
|
|
|
|
utf8 and close down gracefully if other ASN-1 errors occur.
The reason certificate_unknown that is used as ALERT for ASN-1 encoding failure is described as:
Some other (unspecified) issue arose in processing the
certificate, rendering it unacceptable.
|
|
|
|
|
|
|
|
|
|
OTP-10106
OTP-10107
|
|
by providing extra redundant information to crypto.
|
|
Updates for ssh that needs to restarted so no need for soft upgrade
|
|
Also improved test suites to avoid copying of users keys to
test server directories as this is a security liability
|
|
to deal with changes to the pkits suite.
|
|
|
|
ASN-1 compiler is fixed.
|
|
|
|
|
|
|
|
This reverts commit a3193f17e111492bf508057ae6a26d0d7c1bc4fc.
|
|
This reverts commit c7e5f7576e213060cbb332be64a7c3798f6a2cc2.
|
|
Updates version and appup-file
|
|
|
|
|
|
|
|
|
|
|
|
This patch allows the public_key module to decode and encode RSA and DSA
keys encoded using the SubjectPublicKeyInfo format. When
pem_entry_encode is called on an RSA or DSA public key type, the key is
wrapped in the SubjectPublicKeyInfo format.
|
|
|
|
Data to sign and verify should be inputed as binaries.
Also cleaned up and moved some dialyzer specs.
|
|
|
|
|
|
Conflicts:
lib/public_key/src/pubkey_cert.erl
|
|
maint-r14
* ia/ssl-and-public_key/verify_fun_peer_awarness/OTP-8873:
Peer awarness
|
|
* ia/public_key/basic_constraints/OTP-8867:
Better handling of v1 and v2 certificates.
|
|
Changed the verify fun so that it differentiate between the peer
certificate and CA certificates by using valid_peer or valid as the
second argument to the verify fun. It may not always be trivial or
even possible to know when the peer certificate is reached otherwise.
|
|
V1 and v2 certificates does not have any extensions
so then validate_extensions should just accept that
there are none and not end up in missing_basic_constraints clause.
|
|
* ia/public_key/basic_constraints/OTP-8867:
Better handling of v1 and v2 certificates.
|
|
* ia/ssl-and-public_key/backwards-compatibility/OTP-8858:
Backwards compatibility
Conflicts:
lib/ssl/src/ssl_certificate_db.erl
Use short INFO-message. Debugging information can be fairly
easily recreated so we do not want to clutter the logs.
|
|
Changed implementation to retain backwards compatibility for old
option {verify, 0} that shall be equivalent to {verify, verify_none},
also separate the cases unknown CA and selfsigned peer cert, and
restored return value of deprecated function public_key:pem_to_der/1.
|
|
V1 and v2 certificates does not have any extensions
so then validate_extensions should just accept that
there are none and not end up in missing_basic_constraints clause.
|
|
DSS-Params may be null in a certificate as it can inherit the
parameters.
Also ignore CA-certs that do not follow ASN-1 spec in RFC 5280.
|
|
|
|
Added the functionality so that the verification fun will be called
when a certificate is considered valid by the path validation to allow
access to eachs certificate in the path to the user application.
Removed clause that only check that a extension is not critical,
it does alter the verification rusult only withholds information from
the application.
Try to verify subject-AltName, if unable to verify it let
application try.
|
|
|
|
Changed the behavior of the verify_fun option so that
the application can be responsible for handling path validation
errors even on the server side. Also replaced the not yet
documented validate_extensions_fun to be handled by the
verify_fun instead.
If the verify callback fun returns {fail, Reason}, the verification process is
immediately stopped and an alert is sent to the peer and the TLS/SSL
handshake is terminated. If the verify callback fun returns {valid,
UserState}, the verification process is continued. If the verify callback
fun always returns {valid, UserState}, the TLS/SSL handshake will not be
terminated with respect to verification failures and the connection
will be established. The verify callback fun will also be
able to verify application specific extensions.
|