set a random certificate subject

[marten-seemann]

Fixes #97. @peterargue, can you confirm that this fixes the problem with the Java implementation?

According to RFC3280, the issuer field must not be empty.

[peterargue]

Thanks for picking this up so quickly @marten-seemann.

I believe there are a few other changes required to be compliant with that RFC. From a quick review it will also need

• Subject: this should include a DN that matches the issuer since it's self-signed.
• Version: this should be v3 (0x2) to support adding extensions https://datatracker.ietf.org/doc/html/rfc3280#section-4.1.2.9

the general requirement (https://datatracker.ietf.org/doc/html/rfc3280#section-4.1.2):

Every TBSCertificate contains the names of the subject and issuer, a public key associated with the subject, a validity period, a version number, and a serial number.

I may not have captured everything, and there may be some additional fields required for a self-signed cert since it's also a CA.

[marten-seemann]

Subject: this should include a DN that matches the issuer since it's self-signed.

Not sure what to do here, we're using tmpl for both template and parent in x509.CreateCertificate. Can you suggest a fix?

Version: this should be v3 (0x2) to support adding extensions https://datatracker.ietf.org/doc/html/rfc3280#section-4.1.2.9

I'm pretty sure we don't need to set this manually, at least parsing a certificate generated with keyToCertificate yields a cert that already has a 3 set here.

[peterargue]

You're right, version is populated by default: https://github.com/golang/go/blob/master/src/crypto/x509/x509.go#L1551-L1560

Looks like you just need to pass the pkix.Name as Subject (instead of issuer) and CreateCertificate will populate the issuer field automatically.

The other fields like KeyUsage/ExtKeyUsage/BasicConstraintsValid/IsCA are probably not strictly required. cURL doesn't require them anyway. Some clients may want a CN in the subject field that matches the hostname.

cURL specifically complains about the NotBefore containing a zero time. That may be a client implementation issue, but a start time with a real timestamp might help.
e.g.

NotBefore:    time.Now().Add(-24 * time.Hour),

[marten-seemann]

cURL specifically complains about the NotBefore containing a zero time. That may be a client implementation issue, but a start time with a real timestamp might help.

That's weird. Probably not worth to debug this further, we can just set the time here.

[marten-seemann]

@peterargue Can you confirm if this works asap? We might be able to include this fix in the go-libp2p v0.16.0 release then.

[peterargue]

Looks good. I've reached out to our community member that ran into this issue to test, but from code inspection of the java library, this should parse correctly.

[peterargue]

nit: subjectSN

[vyzo]

so why does it have to be random? We could just have the peer ID or a constant string like libp2p.

[marten-seemann]

It needs to be unique, so a constant string doesn’t work. Random because that will prevent people from using this value, which might break later when we see the need to change it.

[peterargue]

Random because that will prevent people from using this value, which might break later when we see the need to change it.

what's the concern here? that implementers might use the internal value you set within their logic and that could break if you decide to change the cert format?

You could get around that by accepting a cert template. then implementers can define their own settings and the library is only responsible for adding the extension. You could also introduce a version to the signedKey struct if you want a way to manage compatibility between releases.

[vyzo]

so why not use the peer ID?

[marten-seemann]

so why not use the peer ID?

what's the concern here? that implementers might use the internal value you set within their logic and that could break if you decide to change the cert format?

Exactly. It's been a painful lesson learned from protocol design: If you're exposing something, someone will come to rely on this. That's why the IETF has introduced the concept of GREASE in recent years.

You could get around that by accepting a cert template. then implementers can define their own settings and the library is only responsible for adding the extension. You could also introduce a version to the signedKey struct if you want a way to manage compatibility between releases.

That seems out of scope for this PR.