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

[Mike Ounsworth <[e-mail]>]

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