Re: [lamps] New Liaison Statement, "Liaison statement to IETF on RFC 5280 attribute length limitations"

[Rob Stradling <[e-mail]>]

Ryan wrote:
> RFC 5280 should be seen as exactly what it specifies it is: a narrower profile of X.509 suitable for Internet applications.

+1, and retaining the traditional "upper bounds" in RFC5280 can legitimately be seen as part of that narrower profiling.

ISTM that if ETSI don't want to be restricted by RFC5280's narrower profile, then ETSI should consider profiling X.509 directly and not referencing RFC5280 at all.

IETF believes in Rough Consensus and Running Code.  Breaking backwards compatibility would be likely to break Running Code, and I dare say it would do serious damage to Rough Consensus too.

> This would be no different than if the BasicConstraints PDU was redefined from being SEQUENCE { BOOLEAN, INTEGER } to being SEQUENCE { SEQUENCE, BOOLEAN, INTEGER }. We would, undoubtedly, agree that is a backwards-incompatible change, and the solution for such a need would be simply a BasicConstraintsV2 structure with that syntax, and, corresponding, a new id-ce-basicConstraintsV2 object identifier to identify that extension.

Funnily enough, this already happened.  🙂

https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ipki-part1-01#section-4.2.6 defined a draft version of Basic Constraints that was altered before RFC2459 defined what we use today.

I'm not sure if there's an official repository of PKIX certificate extension OIDs that have been deprecated due to backwards-incompatible changes, so in the absence of that I give you this...

> curl -s https://lapo.it/asn1js/oids.js | grep basicConstraints
"2.5.29.10": { "d": "basicConstraints", "c": "X.509 extension.  Deprecated, use 2 5 29 19 instead", "w": true },
"2.5.29.13": { "d": "basicConstraints", "c": "X.509 extension.  Deprecated, use 2 5 29 19 instead", "w": true },
"2.5.29.19": { "d": "basicConstraints", "c": "X.509 extension" },

________________________________
From: Spasm <[e-mail]> on behalf of Ryan Sleevi <[e-mail]>
Sent: 12 January 2022 17:00
To: Stefan Santesson <[e-mail]>
Cc: Roman Danyliw <[e-mail]>; Ryan Sleevi <[e-mail]>; Russ Housley <[e-mail]>; Limited Additional Mechanisms for PKIX and SMIME Discussion List <[e-mail]>; Benjamin Kaduk <[e-mail]>; Tim Hollebeek <[e-mail]>
Subject: Re: [lamps] New Liaison Statement, "Liaison statement to IETF on RFC 5280 attribute length limitations"


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.



On Wed, Jan 12, 2022 at 10:56 AM Stefan Santesson <[e-mail]<mailto:[e-mail]>> wrote:

Ryan,

Very interesting discussion, but unfortunately off-topic.

Hi Stefan,

Could you clarify what's off-topic? I think this is very core to the discussion regarding compatibility, as highlighted by Russ and Peter, so perhaps I'm explaining these things poorly, since it sounds like there's still some resulting confusion or disagreement.

The issue at hand is - Should RFC 5280 deviate from X.520 with regard to max size limits on X.520 defined attributes.

If so, then please specify:

1) Why that is a good idea, and

Yes. That ship has sailed, software has shipped, and we deal with it going forward. The issue is that X.509 made a backwards incompatible change, whether intentionally or ill-conceived.

2) How a certificate verifying application would know if the X.520 definition of the attribute or the RFC 5280 definition of the same attribute should be enforced?

Simple. An application that uses the ASN.1 modules from RFC 5280, or, alternatively, RFC 5912, will not be able to decode such certificates. RFC 5280 should be seen as exactly what it specifies it is: a narrower profile of X.509 suitable for Internet applications.

Constraints are part of the type definition, as covered by X.682. They affect the encoder and decoder, and thus, are key to understanding interoperability. The issue is that X.520 redefined the types, without redefining the type identifier, and thus, compatibility problems are introduced for anything using the existing type specifier.

The request is for RFC 5280 to update the types to match X.520, thus introducing the same redefinition issue. This would be no different than if the BasicConstraints PDU was redefined from being SEQUENCE { BOOLEAN, INTEGER } to being SEQUENCE { SEQUENCE, BOOLEAN, INTEGER }. We would, undoubtedly, agree that is a backwards-incompatible change, and the solution for such a need would be simply a BasicConstraintsV2 structure with that syntax, and, corresponding, a new id-ce-basicConstraintsV2 object identifier to identify that extension.  My discussion of how ETSI can relieve any perceived incompatibilities is precisely to use what has been the recommendation of X.509 for quite some time: if you are defining a new type (as a different constraint inherently is), then identify it with a new type identifier. It's just that simple.