Strictly speaking, the CRLReason is a concept imported from the CRL
profile defined in RFC 5280 Section 5.3.1. However, this is a CRL
extension that is not implemented in mbed TLS. Therefore, this patch
introduces the relevant macros with revocation reasons and error return
codes in x509_crt.h. Also the function x509_ocsp_get_crl_reason() to
parse the CRLReason. If necessary, this code can later be migrated to
x509_crl.c.
The CRL reason ASN1. structure is specified in RFC 5280 Section 5.3.1
as follows:
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
-- value 7 is not used
removeFromCRL (8),
privilegeWithdrawn (9),
aACompromise (10) }
Populate the function x509_ocsp_get_cert_status() with code that parses
the following ASN.1 structure:
CertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
x509_ocsp_get_cert_status() parses the top level CHOICE and IMPLICIT
components. In the case of status good and unknown, their value is both
expected to be NULL because according to RFC 6960 Section 4.2:
UnknownInfo ::= NULL
Therefore, no further parsing is needed here. In the case of status
revoked, the parsing of Revoked info is delegated to a helper function.
Populate the function x509_ocsp_get_responses() that parses the
SEQUENCE OF tag in a BasicOCSPResponse. The function also calls its
helper function x509_ocsp_get_single_response() for each of the
SingleResponse(s) contained. Note that for each SingleResponse,
x509_ocsp_get_responses() must allocate a new internal struct
mbedtls_x509_ocsp_single_response where the parsed data will be
stored.
This change also populates the mbedtls_x509_ocsp_single_response
with the necessary values as specified by RFC 6960 Section 4.1.1.
Populate the function x509_ocsp_get_responder_id() with code that
parses the following X.509 structure:
ResponderID ::= CHOICE {
byName [1] Name,
byKey [2] KeyHash }
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)
Note that here the name is parsed by the helper function
mbedtls_x509_get_name() and the KeyHash's bounds are checked but we
do not ensure that the hash is of the correct length.
Populate the function x509_ocsp_get_response_data() with code that
parses the following ASN.1 structure:
ResponseData ::= SEQUENCE {
version [0] EXPLICIT Version DEFAULT v1,
responderID ResponderID,
producedAt GeneralizedTime,
responses SEQUENCE OF SingleResponse,
responseExtensions [1] EXPLICIT Extensions OPTIONAL }
x509_ocsp_get_response_data() will parse the top-level SEQUENCE and the
two EXPLICIT tags. It delegates the parsing of the individual
subcomponents to x509_ocsp_get_version(), x509_ocsp_get_responder_id(),
x509_ocsp_get_generalized_time(), x509_ocsp_get_responses() and
x509_ocsp_get_extensions().
Populate the function x509_ocsp_get_response() that parses the top
level components of the following ASN.1 structure:
BasicOCSPResponse ::= SEQUENCE {
tbsResponseData ResponseData,
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING,
certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }
The top-level components correspond to the main SEQUENCE and the
EXPLICIT tag.
The added code removed the SEQUENCE component from the following ASN.1
structure:
ResponseBytes ::= SEQUENCE {
responseType OBJECT IDENTIFIER,
response OCTET STRING }
The parsing for responseType and response is delegated to
x509_ocsp_get_response_type() and x509_ocsp_get_response() respectively.
Populate the function x509_ocsp_get_response_status() that parses the
OCSPResponseStatus:
OCSPResponseStatus ::= ENUMERATED {
successful (0), -- Response has valid confirmations
malformedRequest (1), -- Illegal confirmation request
internalError (2), -- Internal error in issuer
tryLater (3), -- Try again later
-- (4) is not used
sigRequired (5), -- Must sign the request
unauthorized (6) -- Request unauthorized
}
The function writes the value into the resp_status field of the
mbedtls_x509_ocsp_response struct.
Add parsing for the OCSPResponse top level components:
OCSPResponse ::= SEQUENCE {
responseStatus OCSPResponseStatus,
responseBytes [0] EXPLICIT ResponseBytes OPTIONAL }
The added code does the following:
1. Parse the top level SEQUENCE
2. Call x509_ocsp_get_response_status() which will parse the
responseStatus in the future
3. If there is any data left in the buffer, parses the EXPLICIT
tag and calls x509_ocsp_get_response_bytes() which will parse
the responseBytes in the future
At this stage, the main framework for the code is being set up. The idea
is that each function will parse the top level components of the ASN1
objects and hand over the parsing of each of the individual
sub-components to other functions. Also, note that each function its
responsible for checking that:
1. At the begining, there is enough space in the buffer p to parse
whatever is being processed before end.
2. Prior to returning, the length specified in the ASN1 encoding
matches the number of bytes consumed from the buffer p.
3. The lengths of any intermediate sub-components (such as EXPLICIT
tags) parsed matches the number of bytes consumed by the called
functions x509_ocsp_get_*().
OCSP by itself is a protocol between an OCSP responder and a client.
The protocol messages are encoded in X.509 format, so I have created
the place-holder files x509_ocsp.c and x509_ocsp.h that will contain
the X.509 parser and verification for OCSP messages.
As noted in #557, several functions use 'index' resp. 'time'
as parameter names in their declaration and/or definition, causing name
conflicts with the functions in the C standard library of the same
name some compilers warn about.
This commit renames the arguments accordingly.
Allow forcing 64-bit integer type for bignum operations. Also introduce
the macro MBEDTLS_TYPE_UDBL to allow configuration of the double length
integer in unknown compilers.
Rename the macro MBEDTLS_PLATFORM_SETUP_ALT to
MBEDTLS_PLATFORM_SETUP_TEARDOWN_ALT to make the name more descriptive
as this macro enables/disables both functions.
Add the following two functions to allow platform setup and teardown
operations for the full library to be hooked in:
* mbedtls_platform_setup()
* mbedtls_platform_teardown()
An mbedtls_platform_context C structure is also added and two internal
functions that are called by the corresponding setup and teardown
functions above:
* mbedtls_internal_platform_setup()
* mbedtls_internal_plartform_teardown()
Finally, the macro MBEDTLS_PLATFORM_SETUP_ALT is also added to allow
mbedtls_platform_context and internal function to be overriden by the
user as needed for a platform.
The functions mbedtls_aes_decrypt and mbedtls_aes_encrypt have been
superseded by mbedtls_aes_internal_decrypt and
mbedtls_aes_internal_encrypt, respectively. Alternative
implementations should now only replace the latter, and leave the
maintenance wrapper definitions of the former untouched.
This commit clarifies this in the documentation of the respective
configuration options MBEDTLS_AES_DECRYPT_ALT and
MBEDTLS_AES_ENCRYPT_ALT.
Protecting the ECP hardware acceleratior with mutexes is inconsistent with the
philosophy of the library. Pre-existing hardware accelerator interfaces
leave concurrency support to the underlying platform.
Fixes#863
Document the preconditions on the input and output buffers for
the PKCS1 decryption functions
- mbedtls_rsa_pkcs1_decrypt,
- mbedtls_rsa_rsaes_pkcs1_v15_decrypt
- mbedtls_rsa_rsaes_oaep_decrypt
* restricted/iotssl-1398:
Add ChangeLog entry
Ensure application data records are not kept when fully processed
Add hard assertion to mbedtls_ssl_read_record_layer
Fix mbedtls_ssl_read
Simplify retaining of messages for future processing
There are situations in which it is not clear what message to expect
next. For example, the message following the ServerHello might be
either a Certificate, a ServerKeyExchange or a CertificateRequest. We
deal with this situation in the following way: Initially, the message
processing function for one of the allowed message types is called,
which fetches and decodes a new message. If that message is not the
expected one, the function returns successfully (instead of throwing
an error as usual for unexpected messages), and the handshake
continues to the processing function for the next possible message. To
not have this function fetch a new message, a flag in the SSL context
structure is used to indicate that the last message was retained for
further processing, and if that's set, the following processing
function will not fetch a new record.
This commit simplifies the usage of this message-retaining parameter
by doing the check within the record-fetching routine instead of the
specific message-processing routines. The code gets cleaner this way
and allows retaining messages to be used in other situations as well
without much effort. This will be used in the next commits.
