You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Server certificates for the M4d interface in the 5GMS Application Server have been implemented in issue 5G-MAG/rt-5gms-application-server#9. This issue tracks the same feature being added to the 5GMS Application Function.
The certificates will ultimately be managed by Application Providers using the M1 interface and passed to the relevant Application Server(s) via the M3 interface. Both these interfaces have yet to be implemented so this issue proposes that initially the certificates are read from the same Certifictes JSON file that the current development implementation for the 5GMS Application Server uses. This will then act as a prerequisite in the development of the M3 interface, so that certificates can be passed via M3 to any relevant AS. It will also be the foundation for certificate management for an implementation of the M1 interface.
Implementation
The Certificates JSON file is a mapping of certificate ID to certificate file path. Any relative file path is treated as being relative to the Certificates JSON file. So relative paths (ones that do not start with the directory separator (e.g. /) need to be a concatenation of the directory path of the JSON file, the directory separator and the relative path from the mapping. This mapping should be stored internally in the application function context with the provisioning session information, as each provisioning session can have its own set of certificates.
When a ContentHostingConfiguration is parsed, any certificate IDs present in the distributionConfigurations must be checked against the list of known certificate IDs for the same provisioning session and an error reported if no match is found.
Relevant Standards
5G-MAG/rt-common-shared#12 - M3 interface definition. TS 26.512 sections 4.3.6, 7.3 & annex C.3.2 - Certificate handling in the M1 interface.
Additional context
This is a prerequisite to #7 so that certificate information is available in the AF to be provided on the M3 interface.
The text was updated successfully, but these errors were encountered:
The provisioning session has a key value structure that stores the certificate ID and the absolute path of the certificate.
There is also a function to check the certificate IDs present in the distributionConfigurations against the certificate IDs in the certificate hash map.
Reviewed the code and found a few issues with style, pointer types and some memory leaks. We've addressed these through a pair programming session, so this is now ready.
Description
Server certificates for the M4d interface in the 5GMS Application Server have been implemented in issue 5G-MAG/rt-5gms-application-server#9. This issue tracks the same feature being added to the 5GMS Application Function.
The certificates will ultimately be managed by Application Providers using the M1 interface and passed to the relevant Application Server(s) via the M3 interface. Both these interfaces have yet to be implemented so this issue proposes that initially the certificates are read from the same Certifictes JSON file that the current development implementation for the 5GMS Application Server uses. This will then act as a prerequisite in the development of the M3 interface, so that certificates can be passed via M3 to any relevant AS. It will also be the foundation for certificate management for an implementation of the M1 interface.
Implementation
The Certificates JSON file is a mapping of certificate ID to certificate file path. Any relative file path is treated as being relative to the Certificates JSON file. So relative paths (ones that do not start with the directory separator (e.g.
/
) need to be a concatenation of the directory path of the JSON file, the directory separator and the relative path from the mapping. This mapping should be stored internally in the application function context with the provisioning session information, as each provisioning session can have its own set of certificates.When a ContentHostingConfiguration is parsed, any certificate IDs present in the distributionConfigurations must be checked against the list of known certificate IDs for the same provisioning session and an error reported if no match is found.
Relevant Standards
5G-MAG/rt-common-shared#12 - M3 interface definition.
TS 26.512 sections 4.3.6, 7.3 & annex C.3.2 - Certificate handling in the M1 interface.
Additional context
This is a prerequisite to #7 so that certificate information is available in the AF to be provided on the M3 interface.
The text was updated successfully, but these errors were encountered: