HTTPsec Authentication Protocol

The optional certificate directive in an initialization request and an initialization response provides the sending peer's certificate containing its (purported) authentication public key. The directive may also be employed for informational purposes in a challenge response. In some use-cases a peer's public key is prior-knowledge from the perspective of the other peer, and thus the certificate directive is not required.

If employed, its value MUST be a valid URI as specified in [URI] Section 3. Certificates provided by the certificate directive MUST be in X509 [X509] certificate format to allow (if required) the use of a Public Key Infrastructure.

Implementations MAY support either or all of the following:

transmission of the X509 certificate itself using a "data" URI scheme. [DATA]. For example:
```
certificate=data:application/x-x509-user-cert;base64,MIGfMA0GCSqGSI...
```
(the value is lengthy and has therefore been abbreviated; the terminating ellipsis "..." would NOT appear in an actual value)
provision of a URL for retrieving the X509 certificate. For example:
```
certificate=http://alice.example.com/my-cert
```
use of the bespoke URI "this:entity-body" to indicate that the X509 certificate is carried in the message entity-body. For example
```
certificate=this:entity-body
```

In all cases, the Mine-Type of the certificate payload MUST be "application/x-x509-user-cert". Certificates in entity-bodies may optionally have the PEM specified header, footer and line breaks.

Note that in the first usage, the certificate payload itself features in the Initialization Transcript and its presence in the initialisation stage is thus authenticated by the signature. This may be considered favourable in some use-cases.