Re: [lamps] [EXTERNAL] Re: I-D Action: draft-ietf-lamps-im-keyusage-00.txt

[Rohan Mahy <[e-mail]>]

We clearly don't want someone reusing keys for multiple purposes. What I
think this allows is for example.com's root CA to delegate to the
foo-bar-messenger.example.com CA that is only issuing certs with the IM
identity EKU. and example.com might further add an X.509 NameConstraint
saying that foo-bar-messenger can only issue certs with a URI in SAN in the
msg.example.com subdomain. If example.com later merges with a company with
a different messaging service, it could create another delegation to a
different subdomain and both could coexist in parallel without one being
able to forge certificates in the other's domains. In addition, auditing
systems could be on the lookout for (for example) ordinary TLS certificates
issued by either of the IM identity CAs.

I can write this all down in the Security Considerations.

I hope this helps.
Thanks,
-rohan


On Wed, Apr 17, 2024 at 9:38 AM Tim Hollebeek <tim.hollebeek=
[e-mail]> wrote:

> I was going to post something similar.  I’m a big fan of separation these
> days, and it always is hard to know how far to take it.
>
>
>
> What’s critically important is key separation, and that unfortunately has
> to be handled by policy.  I don’t think you can fix it by forcing more
> EKUs, because if we have more IM EKUs, we’re most likely going to just end
> up seeing lots of single certificates with all the EKUs, rendering the
> issue moot.
>
>
>
> Now, granted, having multiple EKUs DOES give people who want separation
> the ability to not do that, and it DOES enable policies that force
> separation … the question is whether people are actually going to do that,
> or are we adding complexity no one needs.  It’s hard to know without
> hearing from the IM folks.
>
>
>
> More concretely, is the IM community likely to be interested in
> certificate policies that say “An IM certificate must only be issued for a
> single protocol, so it must only have one IM protocol EKU” ?  If so,
> multiple EKUs will allow them to accomplish that goal.  If not, it’s less
> interesting and we’re just allocating OIDs because making IANA do more work
> is fun.
>
>
>
> -Tim
>
>
>
> *From:* Spasm <[e-mail]> *On Behalf Of *Michael StJohns
> *Sent:* Wednesday, April 17, 2024 12:26 PM
> *To:* [e-mail]
> *Subject:* Re: [lamps] [EXTERNAL] Re: I-D Action:
> draft-ietf-lamps-im-keyusage-00.txt
>
>
>
> Hi Mike -
>
>
>
> It's the responsibility (and the right) of the relying party to decide
> what's acceptable for a given interaction.  If you followed your argument
> below to its logical conclusion, you would want to have different EKUs for
> TLS1.2 clients vs TLS1.3  clients as they are - at least somewhat -
> different protocols.
>
>
>
> If you want this document to do what you're suggesting, this document
> would need to issue an EKU for each and every well known IM service.  Let's
> not do that.
>
>
>
> Talking about this in the security considerations section does not save
> the argument.
>
>
>
> Hi Rohan -
>
>
>
> That said - section 3 of this document is - underwhelming in its
> explanations of how this might be used and what a relying party might do
> with it.
>
>
>
> Something like: "An IM service operator MAY specify that client
> certificates used to connect to it MUST have this EKU, and that the IM
> service will reject connections negotiated with certificates missing this
> EKU.  This document does not impose any operational requirements on an IM
> service, it only suggests an appropriate use of this EKU."  and "Other IM
> protocol documents  MAY impose more stringent requirements on the
> acceptance of certificates without this specific EKU value than is implied
> by the previous paragraph." and "It is RECOMMENDED that a certificate
> containing this EKU SHOULD NOT also contain either an id-kp-serverAuth or
> id-kp-clientAuth EKU unless this certificate is specifically intended to
> also certify connections to non-IM services."
>
>
>
> And lastly, "This EKU is optionally critical" is just wrong.  Extensions
> are critical, not the tags within them.  An EKU extension may already
> optionally be marked critical so the line is not needed.  Excess EKUs are
> ignored within the extension by the relying party - so there's no semantic
> meaning for this EKU by having the extension marked critical. (And please
> don't try and change this interpretation - you'll break things).
>
>
>
> Later, Mike
>
>
>
> On 4/17/2024 11:57 AM, Mike Ounsworth wrote:
>
> (and IMO, that convincing argument should be in the Security
> Considerations)
>
>
>
> - Mike Ounsworth
>
>
> ------------------------------
>
> *From:* Mike Ounsworth <[e-mail]>
> <[e-mail]>
> *Sent:* Wednesday, April 17, 2024 10:42:00 AM
> *To:* Rohan Mahy <[e-mail]> <[e-mail]>
> *Cc:* Russ Housley <[e-mail]> <[e-mail]>; Rohan
> Mahy <[e-mail]> <[e-mail]>; LAMPS <[e-mail]>
> <[e-mail]>
> *Subject:* RE: [EXTERNAL] Re: [lamps] I-D Action:
> draft-ietf-lamps-im-keyusage-00.txt
>
>
>
> Hey Rohan,
>
>
>
> > “It should be perfectly fine to use this with XMPP, MIMI, or a
> proprietary messaging system.”
>
>
>
> I don’t know the IM space very well, but we hear a lot about
> cross-protocol attacks if you, for example, use the same key with S/MIME
> and PGP. Probably that applies to encryption keys more than signature keys,
> but regardless, I think it’s gonna need more than the words “it should be
> fine” to make a convincing argument that it’s ok to use a single
> certificate across multiple IM protocols :P
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Rohan Mahy <[e-mail]> <[e-mail]>
> *Sent:* Wednesday, April 17, 2024 9:10 AM
> *To:* Mike Ounsworth <[e-mail]>
> <[e-mail]>
> *Cc:* Russ Housley <[e-mail]> <[e-mail]>; Rohan
> Mahy <[e-mail]> <[e-mail]>; LAMPS <[e-mail]>
> <[e-mail]>
> *Subject:* Re: [EXTERNAL] Re: [lamps] I-D Action:
> draft-ietf-lamps-im-keyusage-00.txt
>
>
>
> Thanks Mike, The semantics of the EKU is an Instant Messaging identity. It
> should be perfectly fine to use this with XMPP, MIMI, or a proprietary
> messaging system. Unless you have some reason to do otherwise, a very
> natural way to express this
>
> Thanks Mike,
>
> The semantics of the EKU is an Instant Messaging identity. It should be
> perfectly fine to use this with XMPP, MIMI, or a proprietary messaging
> system.
>
>
>
> Unless you have some reason to do otherwise, a very natural way to express
> this identity would be to use a URI identifier of any relevant scheme in
> the subjectAltName. (XMPP already has a custom SAN identifier type but that
> was not strictly necessary.)
>
>
>
> I'll take a stab at some more generic text for the Intro and Security
> Considerations.
>
>
>
> Thanks again for the review. I will fix the other small errors as well.
>
> -rohan
>
>
>
> On Tue, Apr 16, 2024, 12:14 Mike Ounsworth <[e-mail]>
> wrote:
>
> Hey Rohan,
>
>
>
> I’m a novice on the IM topic, but I’ll provide a review of your document
> anyway (feel free to ignore).
>
>
>
> The introduction mentions that the driving motivation is IM apps built on
> top of MLS, and then says “or others see: MIMI”. Are all IMs considered
> equal, or is it important to be able to say “This cert is for MikeGram, and
> that cert is for RohanChat?”. IE would it be better if this draft created
> the specific EKUs that MIMI needs for the specific IM protocols that you’re
> designing now?
>
>
>
> It would be good to expand the Security Considerations section to be clear
> about what security is gained by using the mechanism, including what the
> expectation is of verifiers who are looking for this EKU. Again, I think
> some discussion of using the same cert across different IM protocols would
> be good.
>
>
>
>
>
> Why is it called id-kp-imUri? Why “Uri”? Perhaps this is clear in the mimi
> arch docs, but could use repeating here.
>
>
>
>
>
> Typo? The IANA Considerations section asks for “id-kp-im-eku”, but the
> ASN.1 Module defines “id-mod-im-eku”. I think the latter is the better
> name, to indicate that this is the identifier of an ASN.1 module.
>
>
>
>
>
> To Russ’ question about whether this draft should also cover SANs: the
> intro already says
>
> “The subjectAltName of these certificates can be an IM URI, for example.”
>
> Out of curiosity, which SAN type would be used for that?
>
>
>
> ---
>
> *Mike* Ounsworth
>
>
>
> *From:* Spasm <[e-mail]> *On Behalf Of *Russ Housley
> *Sent:* Monday, April 15, 2024 4:22 PM
> *To:* Rohan Mahy <[e-mail]>
> *Cc:* LAMPS <[e-mail]>
> *Subject:* [EXTERNAL] Re: [lamps] I-D Action:
> draft-ietf-lamps-im-keyusage-00.txt
>
>
>
> I thought it was worth asking. I think the xmpp: URI in the SAN would be a
> very reasonable solution. Russ On Apr 15, 2024, at 4: 49 PM, Rohan Mahy <rohan.
> mahy@ gmail. com> <rohan.%E2%80%8Amahy@%E2%80%8Agmail.%E2%80%8Acom>
> wrote: Hi Russ, I don't understand why an XmppAddr identifier type
>
> I thought it was worth asking.  I think the xmpp: URI in the SAN would be
> a very reasonable solution.
>
>
>
> Russ
>
>
>
>
>
> On Apr 15, 2024, at 4:49 PM, Rohan Mahy <[e-mail]> wrote:
>
>
>
> Hi Russ,
>
> I don't understand why an XmppAddr identifier type would have been
> strictly needed, since anyone could have put either an xmpp: URI or an im:
> URI into a SAN without any extensions (as a URI type).
>
>
>
> I'm happy to go look at some old discussions, but I don't know the history.
>
> Thanks,
>
> -rohan
>
>
>
>
>
>
>
> On Mon, Apr 15, 2024 at 11:28 AM Russ Housley <[e-mail]>
> wrote:
>
> Rohan:
>
> RFC 6120 defines the way to carry a client name (Jabber ID) in the
> subjectAltName extension.  Should this document be expanded to address
> subjectAltName as well as extended key usage?
>
> Russ
>
>
> > On Apr 15, 2024, at 2:18 PM, [e-mail] wrote:
> >
> > Internet-Draft draft-ietf-lamps-im-keyusage-00.txt is now available. It
> is a
> > work item of the Limited Additional Mechanisms for PKIX and SMIME
> (LAMPS) WG
> > of the IETF.
> >
> >   Title:   X.509 Certificate Extended Key Usage (EKU) for Instant
> Messaging URIs
> >   Author:  Rohan Mahy
> >   Name:    draft-ietf-lamps-im-keyusage-00.txt
> >   Pages:   5
> >   Dates:   2024-04-15
> >
> > Abstract:
> >
> >   RFC 5280 specifies several extended key purpose identifiers
> >   (KeyPurposeIds) for X.509 certificates.  This document defines
> >   Instant Messaging (IM) identity KeyPurposeId for inclusion in the
> >   Extended Key Usage (EKU) extension of X.509 v3 public key
> >   certificates
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-lamps-im-keyusage/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lamps-im-keyusage/__;!!FJ-Y8qCqXTj2!eOQUtDAA8uwHi6mlSlRXJVJrnm_r5CwAKy09oCl_Q3itf786AeEtm2xwcGhxxxWefFHr1_P4naZzm9xvxEoUKqOy538S$>
> >
> > There is also an HTML version available at:
> > https://www.ietf.org/archive/id/draft-ietf-lamps-im-keyusage-00.html
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-lamps-im-keyusage-00.html__;!!FJ-Y8qCqXTj2!eOQUtDAA8uwHi6mlSlRXJVJrnm_r5CwAKy09oCl_Q3itf786AeEtm2xwcGhxxxWefFHr1_P4naZzm9xvxEoUKn1iEEOp$>
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > Spasm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spasm
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!eOQUtDAA8uwHi6mlSlRXJVJrnm_r5CwAKy09oCl_Q3itf786AeEtm2xwcGhxxxWefFHr1_P4naZzm9xvxEoUKhkjFbRj$>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!eOQUtDAA8uwHi6mlSlRXJVJrnm_r5CwAKy09oCl_Q3itf786AeEtm2xwcGhxxxWefFHr1_P4naZzm9xvxEoUKhkjFbRj$>
>
>
>
>
>
> *Any email and files/attachments transmitted with it are intended solely
> for the use of the individual or entity to whom they are addressed. If this
> message has been sent to you in error, you must not copy, distribute or
> disclose of the information it contains. Please notify Entrust immediately
> and delete the message from your system.*
>
> _______________________________________________
>
> Spasm mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/spasm
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>