CertificateService for replacing certificate and private key

We noticed many examples where PEM-encoded certificate files contained both a public portion and a private portion as a single file, so at the time it did not seem necessary to break it apart into two properties due to prior art.

The Redfish Data Model Specification (https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2022.2.pdf) contains additional text to describe the format of what's expected in the string, including the ordering of data (see 6.16.5.2.2 PEM). The forum uses this document to further describe properties or other elements in the model where it's difficult to express in a property description in a schema file. Delimiters are also standardized by RFC7468, where the public certificate is wrapped with "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----", and the private key is wrapped with "-----BEGIN PRIVATE KEY-----" and "-----END PRIVATE KEY-----". Off the shelf tools already parse these contents from what we've found.

1) By that definition today, you're correct in that I would not expect a key to be wrapped with "BEGIN RSA PRIVATE KEY" and "END RSA PRIVATE KEY". However, you can encode an RSA key as a PKCS #8 structure. If we need to expand the usage to specifically allow for PKCS #1, we can raise this for further discussion.

2) Correct; CertificateType is mandatory in the client's request. If the user does not specify this, then the service is expected to reject the request. The reason this is mandatory is because without it, it makes consumption of the raw string very difficult due to similarities in some of the different types. For example, PEM and PEMchain share the same types of delimiters, so knowing this distinction ahead of time gives consumers expectations about the expected contents of the string.