I propose the following text to address the comment:
Vendor-defined KeyPurposeIds used within a PKI governed by the vendor or a group of vendors typically do not pose interoperability concerns, as non-critical extensions can be safely ignored if unrecognized. However, using or misusing KeyPurposeIds outside of their intended vendor-controlled environment can lead to problems with uncertain impacts. Therefore, it is advisable not to rely on vendor-defined KeyPurposeIds. Instead, the specification defines standard KeyPurposeIds to ensure interoperability across various implementations.
Cheers,
-Tiru
On Wed, 6 Sept 2023 at 01:05, Daniel Migault <daniel.migault@xxxxxxxxxxxx> wrote:
Thank Yoav for the review. I agree with Russ that interoperability is the main driver. We will update the text shortly.
Yours,
Daniel
________________________________________
From: Russ Housley <housley@xxxxxxxxxxxx>
Sent: Tuesday, September 5, 2023 2:48 PM
To: Yoav Nir
Cc: IETF SecDir; draft-ietf-lamps-nf-eku.all@xxxxxxxx; Last Call; LAMPS
Subject: Re: Secdir last call review of draft-ietf-lamps-nf-eku-01
Yoav:
I agree that there are many things in the Security Considerations of RFC 5280 that have nothing to do with EKU values.
Perhaps the structure of the paragraph could be improved, but I do not think it is wrong. Let's take is one part at a time.
Vendor-defined KeyPurposeIds that are used in a PKI governed by the
vendor or a group of vendors pose no interoperability concern.
Vendor-defined KeyPurposeIds work fine when only that vendor pays any attention to them. It could add that is because unrecognized KeyPurposeIds are ignored.
Appropriating, or misappropriating as the case may be, KeyPurposeIds
for use outside of their originally intended vendor or group of
vendors controlled environment can introduce problems, the impact of
which is difficult to determine.
Someone outside that vender might get things wrong if they try to use a Vendor-defined KeyPurposeId.
Therefore, it is not favorable to
use vendor-defined KeyPurposeIds.
It is better to use standards-based KeyPurposeIds.
In short, the whole things could probably say that a standard KeyPurposeIds are being defined to ensure interoperability across many implementations.
Russ
> On Sep 2, 2023, at 1:43 AM, Yoav Nir via Datatracker <noreply@xxxxxxxx> wrote:
>
> Reviewer: Yoav Nir
> Review result: Has Nits
>
> Hello.
>
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These comments
> were written with the intent of improving security requirements and
> considerations in IETF drafts. Comments not addressed in last call may be
> included in AD reviews during the IESG review. Document editors and WG chairs
> should treat these comments just like any other last call comments.
>
> I think the first sentence in the Security Considerations section is
> unnecessary. This document does not inherit the security considerations of 5280
> as its scope is nowhere near as broad as that RFC. The rest just about covers
> it. The document does not introduce new security vulnerabilities as it reduces
> (once implemented and deployed) the possibility of misusing keys to sign JWT
> claims, encrypt JSON objects between SEPPs, and to sign OAuth 2.0 access
> tokens, when that was not their intended purpose.
>
> What I find confusing is the the last paragraph of the Introduction:
> Vendor-defined KeyPurposeIds that are used in a PKI governed by the
> vendor or a group of vendors pose no interoperability concern.
> Appropriating, or misappropriating as the case may be, KeyPurposeIds
> for use outside of their originally intended vendor or group of
> vendors controlled environment can introduce problems, the impact of
> which is difficult to determine. Therefore, it is not favorable to
> use vendor-defined KeyPurposeIds.
>
> So, vendor-defined KeyPurposeIds do not cause interoperability issues.
> Misappropriating them can cause (interoperability?) problems. Therefore, they
> should not be used? So do they or don't they cause interoperability issues? I
> suppose this paragraph is there for justifying the need to have these
> KeyPurposeIds come from LAMPS and the IETF rather than some vendor group, but
> I'm not seeing how a 3GPP-controlled assignment would be any more prone to
> misappropriation than an IETF one. Regardless, LAMPS has already taken up this
> work, so perhaps this paragraph is not needed anymore?
>
> Yoav
>
>
>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
