How does RFC 7250 (raw public keys) fit in?

[martinthomson]

Do we replace ASN1Cert, CertificateEntry, or the entirety of the Certificate message body with the SPKI?

[ekr]

Replaces the whole message. Them's the rules.

[martinthomson]

7250 mentions ASN1Cert directly. It probably needs some clarification in this document to avoid confusion.

[ekr]

OK, will fix.

On Wed, Oct 19, 2016 at 7:45 PM, Martin Thomson notifications@github.com
wrote:

7250 mentions ASN1Cert directly. It probably needs some clarification in
this document to avoid confusion.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#722 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABD1oeWxVWKs1Bd-LUSnUrzl5FArRxBNks5q1tXUgaJpZM4Kbkjh
.

[ekr]

We may actually need a 7250-bis. I'm going to leave this for now.

[Lekensteyn]

This is still a problem. RFC 7250 is referenced in several places, but its use in TLS 1.3 is not well-defined.

Section 2 of draft 18 says:

Certificate: [..] Note that if raw public keys [RFC7250] or the cached information extension [RFC7924] are in use, then this message will not contain a certificate but rather some other value corresponding to the server's long-term key. [Section 4.4.1]

Certificate (section 4.4.1) is defined via:

opaque ASN1Cert<1..2^24-1>;

struct {
    ASN1Cert cert_data;
    Extension extensions<0..2^16-1>;
} CertificateEntry;

struct {
    opaque certificate_request_context<0..2^8-1>;
    CertificateEntry certificate_list<0..2^24-1>;
} Certificate;

If the whole Certificate is replaced as suggested by Section 2, then the certificate_request_context is lost. While not a problem for the server certificate message (of which there can be only one), it is not good for client certificates.

In TLS 1.2 there is only one Certificate per handshake. In TLS 1.3 you can have multiple CertificateRequests and Certificate responses (in any order).

Restricting the number of CertificateRequest/Certificate responses (or requiring the context to be the same) is one option, but may complicate the protocol/implementation.
Since the main motivation of RPK is to share public keys with reduced overhead (no need for a full forest of options/extensions), what about replacing the certificate_list field? Overhead is only 1 byte if no context is needed.

[ekr]

Done