Hi Kyle,
On Tue, Nov 5, 2024 at 10:28 AM Kyle Rose <krose@xxxxxxxxx> wrote:
Thanks for your reply. I'm mostly good with your replies and the proposed changes, but I have a few follow-ups, inline:On Mon, Nov 4, 2024 at 1:42 PM Rohan Mahy <rohan.mahy@xxxxxxxxx> wrote:Second, is the worry that CAs might sign a certificate with the wrong
KeyPurposeId? I'm unsure how this specification would prevent that. Or is it
that absent this new purpose, there's nothing preventing a certificate from
being used in both contexts, creating cross-protocol attack risks (as outlined
in section 6 of RFC 9336)?Absent a dedicated key purpose, a certificate with a more general key purpose could be abused in a cross-protocol attack.I reworded the second paragraph as follows:
"Organizations may be unwilling to issue certificates for Instant Message client using a general KeyPurposeId such as `id-kp-serverAuth` or `id-kp-clientAuth`, because of the risk that such certificates could be abused in a cross-protocol attack."Does "organization" here refer to the domain owner, or does it refer to the CA? Because my impression is that CAs in general don't care what you intend to use a certificate for, mostly because they have no control over how a certificate requestor deploys the cert: except in EV cert cases, the CA is really limited to verifying that the requestor controls a given domain.
Organization = organizations that have a CA, but usually enterprise CAs (who do care).
The main incentive to limit a cert to a specific key purpose is for *domain owners* that want to have certificates signed for specific hostnames without the risk of cross-protocol attacks that take advantage of loopholes in trust establishment for TLS connections. A simple example of a risk to be avoided would be someone running a phishing website using a legitimately-signed certificate for chat.example.com that isn't flagged as such by browsers and that receives cookies for example.com.
While I would be delighted if commercial CAs would offer more choices of keyPurpose and more subjectAltName formats, my experience is that they are a little far behind (years) in offering certs for a niche application (tongue in cheek) like instant messaging.
Please let me know if you'd like any additional changes to the text.
Though I think to deal with the above concern, the entire
certificate ecosystem MUST enforce the presence of an appropriate value.
yes.
I wonder if the normative language even needs to be here, versus in the protocol
specification.This was intentional. In order to pass idnits, the document needed to have at least one RFC2119 normative statement.While I don't love the notion of the tail-wagging-the-dog to pass a mechanical sanity check, I think the "MAY" language in section 3 is fine under the assumption that opting-out negatively affects only a given domain and its users. I haven't thought that through completely, however, so it's possible there may be some reason in the future to mandate the inclusion and validation of this extension across all TLS handshakes. Nonetheless, I think it's fine to keep it optional in this context.
thanks,
-rohan
Thanks,Kyle
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
