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

[Mike Ounsworth <[e-mail]>]

Hi Mike,

 

Yup, I’d be fine with that too – more explanation of how a relying party is expected to use this EKU. 

 

Basically, I see that Rohan is trying to tighten things up, which is good, but how far should it be tightened? Is what’s proposed in the document striking the right balance? I think it would be helpful if the document had some discussion of that, and made an argument that this is the right balance.

 

---

Mike Ounsworth

 

From: Spasm <[e-mail]> On Behalf Of Michael StJohns
Sent: Wednesday, April 17, 2024 11:26 AM
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 



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  <mailto:[e-mail]> <[e-mail]>
Sent: Wednesday, April 17, 2024 10:42:00 AM
To: Rohan Mahy  <mailto:[e-mail]> <[e-mail]>
Cc: Russ Housley  <mailto:[e-mail]> <[e-mail]>; Rohan Mahy  <mailto:[e-mail]> <[e-mail]>; LAMPS  <mailto:[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  <mailto:[e-mail]> <[e-mail]> 
Sent: Wednesday, April 17, 2024 9:10 AM
To: Mike Ounsworth  <mailto:[e-mail]> <[e-mail]>
Cc: Russ Housley  <mailto:[e-mail]> <[e-mail]>; Rohan Mahy  <mailto:[e-mail]> <[e-mail]>; LAMPS  <mailto:[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] <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  <mailto:rohan. mahy@ gmail. com> <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. 



_______________________________________________
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!fTAJ3wcdr6L5x_g1jpfx7Yw6DRfRuOs4sYlhtEaRlSd3-xBgorfSTJJ-Gn5QSWKcs5aC98DQXIWDOvyuThL8QO-CCWI$>