feat: plug and charge authorization, basic happy path

[danielgordon-switch-ev]

This implements the basic flow for Plug and Charge authorization.

Still to be done:

• handling the Ongoing case (managing around the short timeouts required by 15118)
• could probably use more testing of the technicalities of certificate handling
• accommodating better for other authorization cases (probably not for this PR)

Note that this prepares the certificate chain and hash data in the form in which OCPP will require them.

I've left some outstanding questions in TODOs for the time being as well -- let's either resolve or make issues for these.

[HugoJP1]

Will add a ticket noting that the verification needs to be more intelligent than this, to figure out which root cert to use.

[danielgordon-switch-ev]

@HugoJP1 Have you done this, or shall I pick it back up?

[danielgordon-switch-ev]

I think this falls under #94 .

[HugoJP1]

Will create a ticket for this.

[tropxy]

isnt this part quite straight forward? in case of Ongoing or Accepted we go to the Authorization state.
in case of rejected then we can answer with an Error code.

we also need to save the state of the authorization in the session here, I believe, because if the auth is successful in the PaymentDetailsReq, then we wont need to request it in the Authorization state and we can move forward. Unless, the ocpp client holds the authorization response and answers immediately if we do another request for the same eMAID.

if the answer "accepted" was not yet received, then we will keep requesting until the timeout (60s)

[danielgordon-switch-ev]

Attached this to the existing #54

[tropxy]

isnt this part quite straight forward? in case of Ongoing or Accepted we go to the Authorization state.
in case of rejected then we can answer with an Error code.

we also need to save the state of the authorization in the session here, I believe, because if the auth is successful in the PaymentDetailsReq, then we wont need to request it in the Authorization state and we can move forward. Unless, the ocpp client holds the authorization response and answers immediately if we do another request for the same eMAID.

if the answer "accepted" was not yet received, then we will keep requesting until the timeout (60s)

[tropxy]

just again a note about the auth option may not be what we want

[danielgordon-switch-ev]

As mentioned, have resolved this.

[tropxy]

added some suggestions and food for thought

[tropxy]

I did some research and this is what we need to do to extract the responder_url

from cryptography.x509.oid import ExtensionOID, AuthorityInformationAccessOID

def get_ocsp_url(cert):
    auth_inf_access = cert.extensions.get_extension_for_oid(ExtensionOID.AUTHORITY_INFORMATION_ACCESS).value
    ocsps = [access_descriptor for access_descriptor in auth_inf_access if access_descriptor.access_method == AuthorityInformationAccessOID.OCSP]
    if not ocsps:
        raise Exception(f'no ocsp server entry in Authority Information Access extension field')
    return ocsps[0].access_location.value

If the Authority Information Access is not found, the method raises a ExtensionNotFound error

References:
https://stackoverflow.com/questions/64436317/how-to-check-ocsp-client-certificate-revocation-using-python-requests-library

https://cryptography.io/en/latest/x509/reference/?highlight=AuthorityInformationAccessOID.CA_ISSUERS#cryptography.x509.Extensions.get_extension_for_oid

https://cryptography.io/en/latest/x509/reference/?highlight=AuthorityInformationAccessOID.OCSP#cryptography.x509.AccessDescription

https://cryptography.io/en/latest/x509/reference/?highlight=AuthorityInformationAccessOID.OCSP#cryptography.x509.oid.AuthorityInformationAccessOID

The information here: https://www.notion.so/switchev/Certificates-944733c8b468493a9e0eeace3b772d6a#3a1c89b988f2432c81c603ab370f879e

can be used to get the ocsp_url using openssl and validate the python code

[tropxy]

Also, to get the hashed info for the OCSP request we can do this:

from cryptography.x509.ocsp import OCSPRequestBuilder

def get_oscp_request(cert: bytes, issuer_cert: bytes):
    """
    cert: The certificate in DER format
    issuer_cert: The certificate used to sign the `cert` certificate, also called the issuer certificate
    """
    cert = load_der_x509_certificate(cert)
    issuer_cert = load_der_x509_certificate(issuer_cert)
    builder = OCSPRequestBuilder().add_certificate(cert, issuer_cert, cert.signature_hash_algorithm)
    return builder.build()

ocsp_request = get_oscp_request(certificate, issuer_cert)

The data can then be accessed through the returned object, for example
ocsp_request.issuer_key_hash.

Not sure if this is better as we need to load the issuer certificate and we may not have the root of the MO, but makes it easier then to extract the needed data. at least it can be used to compare some results...

Reference:
https://cryptography.io/en/latest/x509/ocsp/#cryptography.x509.ocsp.OCSPRequest

[danielgordon-switch-ev]

For some reason I can't respond directly to some of your comments.

The OCSP URL stuff looks good to me -- thanks for digging this up.

On handling authorization, I'd prefer to do this as a separate follow-up PR -- may do some minor refactoring relating to is_authorized as well.

Agreed that we may not want to use the OCSPRequest object if it requires us to have the root certificate.

[danielgordon-switch-ev]

@tropxy What do you think -- is it an unrecoverable failure if the certificate does not provide a URL for an OCSP server, or is there something else we could try in this case?

[tropxy]

As far as I can tell, if we cant obtain the OCSP url, then we cant do the check, then we should answer back that the check failed

[danielgordon-switch-ev]

#96

[tropxy]

As far as I can tell, if we cant obtain the OCSP url, then we cant do the check, then we should answer back that the check failed

[tropxy]

we dont have a guarantee that the MO root will be available in the station. So, we may actually call a evse_controller to get a True/False result for the question "verify contract certificate chain?"

[danielgordon-switch-ev]

#94 for logic when the MO root cannot be obtained.
#97 for doing our best to obtain it.

[tropxy]

If the Auth status is Accepted or Ongoing, yes, the next step shall be the Authorization class, as that is the message the EV will send after reception of the PaymentDetailsRes

[tropxy]

LGTM