Add support for server certificates at M4d

[dsilhavy]

Feature description

Each X.509 server certificate [8] presented by the 5GMSd AS at reference point M4d or at reference point xMB-U is represented by a Server Certificate resource at M1d.

Relevant specifications and corresponding sections

26.501 - 5G Media Streaming (5GMS); General description and architecture (Release 17)
26.512 - 5G Media Streaming (5GMS); Protocols (Release 17)

[davidjwbbc]

Certificates (for the purposes here a certificate includes the public certificate, private key and any intermediate CA certificates) would normally be pushed from the AF to the AS via the M3 interface. At present we don't have an M3 interface, so until we do I propose that the the certificates are configured using a JSON configuration file which is a simple mapping of certificate Ids to PEM files on the local system. Later on this mapping will be derived from certificates registered with the AS via M3 and will require the AS to store the certificates locally and maintain this mapping.

Example certificates.json:

{
  "cert1": "/var/lib/5gms/as/certificates/cert1.pem"
}

This will then allow the ContentHostingConfiguration to reference the certificate to provide an https distribution point:

{
  "name": "Big Buck Bunny",
  "ingestConfiguration": {
    "pull": true,
    "protocol": "urn:3gpp:5gms:content-protocol:http-pull-ingest",
    "entryPoint": "https://ftp.itec.aau.at/"
  },
  "distributionConfigurations": [
    {
      "canonicalDomainName": "localhost",
      "domainNameAlias": "",
      "certificateId": "cert1",
      "pathRewriteRules": [
	{
	  "requestPattern": "^/m4d/provisioning-session-[^/]*/",
	  "mappedPath": "/datasets/DASHDataset2014/BigBuckBunny/4sec/"
	}
      ]
    }
  ]
}

...or for both HTTP and HTTPS:

{
  "name": "Big Buck Bunny",
  "ingestConfiguration": {
    "pull": true,
    "protocol": "urn:3gpp:5gms:content-protocol:http-pull-ingest",
    "entryPoint": "https://ftp.itec.aau.at/"
  },
  "distributionConfigurations": [
    {
      "canonicalDomainName": "localhost",
      "domainNameAlias": "",
      "pathRewriteRules": [
	{
	  "requestPattern": "^/m4d/provisioning-session-[^/]*/",
	  "mappedPath": "/datasets/DASHDataset2014/BigBuckBunny/4sec/"
	}
      ]
    },
    {
      "canonicalDomainName": "localhost",
      "domainNameAlias": "",
      "certificateId": "cert1",
      "pathRewriteRules": [
	{
	  "requestPattern": "^/m4d/provisioning-session-[^/]*/",
	  "mappedPath": "/datasets/DASHDataset2014/BigBuckBunny/4sec/"
	}
      ]
    }
  ]
}

The certificates JSON file can be provided as an optional second command line option to the application server process:

Syntax: 5gms-application-server [-h] [-c <config>] <ContentHostingConfiguration-JSON-file> [<certificates-JSON-file>]

This maintains compatibility with MVP#1.

If a "certificateId" property is present in the ContentHostingConfiguration that does not match an Id from the certificates file (or if the certificates filename is not given) then the program will abort with a configuration error.

[rjb1000]

@davidjwbbc: To emphasise that certificateId is alphanumeric, I suggest we change the name to something like cert1 in this initial implementation.

(In the longer term, it would be nice for our implementation of the M1 Server Certificates Provisioning API to extract the certificate serial number from the X.509 PEM bundle and use the ASCII hex representation of that, padded out to 40 nybbles, as the value of certificateId.)