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.

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

Mg c07 authorize contract certs #527

Closed
wants to merge 12 commits into from

Conversation

mennodegraaf
Copy link
Contributor

Describe your changes

  • Refactor verify_certificate so that it can also be used for ISO P&C chain validation
  • Allow generation of OCSP request data
  • Implement ISO P&C in line with OCPP C07 requirements

Issue ticket number and link

#324

Checklist before requesting a review

  • I have performed a self-review of my code
  • I have made corresponding changes to the documentation
  • I read the contribution documentation and made sure that my changes meet its requirements

Menno de Graaf added 3 commits March 13, 2024 15:39
Signed-off-by: Menno de Graaf <[email protected]>
Signed-off-by: Menno de Graaf <[email protected]>
Signed-off-by: Menno de Graaf <[email protected]>
Copy link
Contributor

@marcemmers marcemmers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is still something to discuss for this one.

std::vector<OCSPRequestData> ChargePoint::generate_ocsp_data(const CiString<5500>& certificate) {
std::vector<OCSPRequestData> ocsp_request_data_list;
const auto ocsp_data_list =
this->evse_security->get_ocsp_request_data(certificate.get(), ocpp::CaCertificateType::MO);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't get where the MO type comes from here. I would either pass it to the function that it needs to be an MO root or change the function name to show that its OCSP data for an MO certificate chain.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

During P&C the OCSP data needs to be generated for a contract chain, therefore MO is the default. If there are other use cases, we could indeed add the CertificateType as an argument.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noticed that EVerest/libevse-security#61 is another use case.

@@ -335,6 +335,31 @@ CaCertificateType string_to_ca_certificate_type(const std::string& s);
/// \returns an output stream with the CaCertificateType written to
std::ostream& operator<<(std::ostream& os, const CaCertificateType& ca_certificate_type);

enum class CertificateValidationResult {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this done before so maybe not the right time, but I think we should prevent making a copy of an enum definition at all cost. This is going to be really error prone.

If we want it in scope I would suggest using some kind of using statement here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess how I did it is similar to how it is typically done in libocpp. @Pietfried any suggestions?


// C07.FR.01: When CS is online, it shall send an AuthorizeRequest
// C07.FR.02: The AuthorizeRequest shall at least contain the OCSP data
// TODO: local validation results are ignored if response is based only on OCSP data, is that acceptable?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure about this. One could even argue that we should always generate the OCSP data in libocpp instead of allowing this data coming from the outside but I don't know if that is possible. Are there sources that only give us the OCSP data?

The way it is now a caller to this function can give a cert chain with different data then the OCSP contains so then we might need to check. In that case not even having OCSP as an argument would be just as quick.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I implemented it this way to avoid breaking existing functionality. AFAIK in EVerest, it is possible that local chain validation and generation of OCSP data is done already by the ISO15118 module.

}
} else {
// C07.FR.07: CS shall not allow charging
response.idTokenInfo.status = AuthorizationStatusEnum::NotAtThisTime;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest a different return type here. NotAtThisTime holds a special meaning an could be used for UI purposes later. In this case I would just go with Unknown.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have set it to NotAtThisTime for this purpose as the CSMS is offline. If the user comes back some other time if the CSMS if online again, authorization might be ok. The user gets feedback that the failed authorization is because of some problem in the CS, not with his contract.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough but that would be for other modules to decide what to show to the used based on the online status. NotAtThisTime is a specific return type specified in OCPP and in my opinion should hold special meaning if the CSMS reports this.

In other cases when we are offline and not able to authorize we also respond with unknown.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, done

// Temporary variable that is set to true to avoid immediate response to allow the local auth list
// or auth cache to be tried
bool tryLocalAuthListOrCache = false;
bool forwardToCsms = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: rename to forwardedToCsms. I now expected you to still take an action in the if statement checking this.

Menno de Graaf added 2 commits March 20, 2024 08:31
Signed-off-by: Menno de Graaf <[email protected]>
Signed-off-by: Menno de Graaf <[email protected]>
@Pietfried
Copy link
Contributor

Closed because replaced by: #536

@Pietfried Pietfried closed this Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants