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

[Rohan Mahy <[e-mail]>]

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> 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$>
>
>
>