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

[Michael StJohns <[e-mail]>]

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