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

[Mike Ounsworth <[e-mail]>]

(and IMO, that convincing argument should be in the Security Considerations)

- Mike Ounsworth

________________________________
From: Mike Ounsworth <[e-mail]>
Sent: Wednesday, April 17, 2024 10:42:00 AM
To: Rohan Mahy <[e-mail]>
Cc: Russ Housley <[e-mail]>; Rohan Mahy <[e-mail]>; LAMPS <[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]>
Sent: Wednesday, April 17, 2024 9:10 AM
To: Mike Ounsworth <[e-mail]>
Cc: Russ Housley <[e-mail]>; Rohan Mahy <[e-mail]>; LAMPS <[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]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Russ Housley
Sent: Monday, April 15, 2024 4:22 PM
To: Rohan Mahy <[e-mail]<mailto:[e-mail]>>
Cc: LAMPS <[e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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.