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

From: Liaison Statement Management Tool <[email-masked]>
Date: Tue, 11 Jan 2022 14:47:39 -0800

Title: Liaison statement to IETF on RFC 5280 attribute length limitations
Submission Date: 2022-01-11
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1773/

From: Russ Housley <[email-masked]>
To: Russ Housley <[email-masked]>,Tim Hollebeek <[email-masked]>
Cc: Tim Hollebeek <[email-masked]>,Russ Housley <[email-masked]>,Benjamin Kaduk <[email-masked]>,Roman Danyliw <[email-masked]>,Limited Additional Mechanisms for PKIX and SMIME Discussion List <[email-masked]>
Response Contacts: 
Technical Contacts: 
Purpose: For information

Body: ETSI brings to the attention of IETF that the limitation of the length of certain attributes indicated in RFC 5280 Annex A.1 mandatory "Upper bounds" which make the document inappropriate for current use.
RFC 5280 is widely referenced as a requirement or recommendation in many internationally recognised PKI specifications including:

-	CA/Browser Forum guidelines for the Issuance And Management of Extended Validation Certificates
-	ETSI EN 319 412-x  Electronic Signatures and Infrastructures (ESI); Certificate Profiles

These specifications include requirements for certain attributes to be based upon full names as held in official records / registers.  In particular, this applies to registered names held in X.509 attributes:
-	subject: organizationName
-	subject: givenName
-	subject: surname

and can also apply to:
-	subject: commonName
-	subject: pseudonym
-	subject: organizationalUnitName

In a number of cases the full name as held in official records / registers is larger than the than the limit stated in RFC 5280 Annex A.1 under "Upper bounds".  For example, an analysis of a sample of 5000 from 2 million registrations of Legal Entity Identifiers, as made available through the Global Legal Entity Identifier Foundation (see https://search.gleif.org/#/search/), showed 110 cases where the identifier is more than 64 characters).  Thus, roughly 2% of organization identifiers officially registered exceed the mandatory limit indicated in RFC 5280 stated as follows:

--  specifications of Upper Bounds MUST be regarded as mandatory
--  from Annex B of ITU-T X.411 Reference Definition of MTS Parameter
--  Upper Bounds
:
:
ub-organization-name INTEGER ::= 64

Similar problems have been reported with the use of European national registers for personal and organization names.

Since 11/2008 the attributes used in certificate subject names, as defined in X.520, have been changed from being size limited to an " UnboundedDirectoryString".  It is considered that modern PKI implementations support the X.520 "UnboundedDirectoryString" for name attributes.

ETSI strongly urges IETF to supersede RFC 5280 with a specification including limits based on X.520, instead of X.411 Annex B which has not been updated since 1999.  Until then ETSI is having to give specific exclusions to its references to RFC 5280 which is causing unnecessary concern with the adoption of PKIs based on IETF RFCs.
Attachments:

    ESI(21)000140r1_Liaison_statement_to_IETF_on_RFC_5280_attribute_length_limit.docx
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2022-01-11-esti-tc-esi-lamps-liaison-statement-to-ietf-on-rfc-5280-attribute-length-limitations-attachment-1.docx

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 Jan 2022 00:23:19 +0100

I support this liaison statement.

IMO this issue should be addressed and fixed.

I'm not sure whether the appropriate solution is an update or a bis
document.

/Stefan

Den 2022-01-11 kl. 23:47, skrev Liaison Statement Management Tool:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 11 Jan 2022 18:57:48 -0500

> I'm not sure whether the appropriate solution is an update or a bis

I disagree with Stefan's conclusion and do not support updating this
document.

The issue here is one of backwards compatibility, and has been discussed
several times in the past, such as
https://mailarchive.ietf.org/arch/msg/pkix/nWgnNZHh2w2l-WfbHKozpm2IWcQ/ and
https://mailarchive.ietf.org/arch/msg/pkix/3Rg8ChXgvcmvSlM10ECDI7c2Dik/

There is no compatibility issue with the CA/Browser Forum documents, which
address what CAs can do, so this is primarily one with ETSI.

There are immediately available technical solutions for ETSI that do not
introduce the interoperability concerns that redefining 5280 would incur
(and have been noted, for years). For example, given that the purpose of
these documents is to convey certain prescriptive requirements on the
vetting of that information and its source, nothing prevents the use of a
distinct Attribute Type and Value within an ETSI OID arc to convey that
information as suitable.

The general argument against that is neither one of interoperability nor
compatibility, but rather, the inconvenience that such an approach would
not lead to the preferred display within existing/legacy software. That
does not, on its face, seem to be a compelling justification, especially
since the issue entirely disappears if/when software updates to support
these ETSI features, which are already necessary for other elements of the
ETSI specifications (e.g. the various qualified limitations)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Jan 2022 19:28:41 -0500

Ryan Sleevi <[email-masked]> wrote:
    > incur (and have been noted, for years). For example, given that the
    > purpose of these documents is to convey certain prescriptive
    > requirements on the vetting of that information and its source, nothing
    > prevents the use of a distinct Attribute Type and Value within an ETSI
    > OID arc to convey that information as suitable.

Agreed.

    > The general argument against that is neither one of interoperability
    > nor compatibility, but rather, the inconvenience that such an approach
    > would not lead to the preferred display within existing/legacy
    > software. That does not, on its face, seem to be a compelling
    > justification, especially since the issue entirely disappears if/when
    > software updates to support these ETSI features, which are already
    > necessary for other elements of the ETSI specifications (e.g. the
    > various qualified limitations)

I think you are saying that if the software is updated to display >64
characters, then it could equally be updated to display this new OID.

I think that the downside is that for things less than 64, what should ETSI do?

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 11 Jan 2022 19:45:18 -0500

> I think that the downside is that for things less than 64, what should

Oh, no, I was trying to convey that the relevant ETSI specifications
already introduce a number of extensions that require updating software. So
if the concern is that "Software needs to be updated to display a friendly
ETSI name for this OID from ETSI's arc", and that's seen as a reason
against such a simple change, then it doesn't hold up, because "Software
needs to be updated to display other ETSI qualified attributes".

Basically, the choice is "compatibility issue for existing software" or
"updates for new software for better display", and the latter seems
eminently preferable and entirely reasonable. This is why we have OIDs that
can be assigned in AttributeTypeAndValues.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 Jan 2022 09:55:53 +0100

Ryan,

I have to shamefully admit that my skills in English is not good enough
to decode your message with certainty. Despite reading it over and over.

Can you elaborate in more plain language?

Are you actually suggesting that the ETSI standards should move away
from using X.520 attributes (that actually are defined without size
limitations since 2008) and define copies of these attributes under ETSI
OID arc being an exact copy of the current X.520 definition of the same
attributes?

I hope that is not what you seriously suggest.

The problem here is that the attributes referred to in RFC 5280 are not
defined by IETF. They are defined by ITU X.520. ITU updated them in 2008
to lift the 64 character limitation. RFC 5280 is not up to date on this
matter. As simple as that.

And the 64 character limitation makes no sense what so ever. There is
reason what so ever to defend that limitation. I have used 64+ attribute
values in certs forever and never seen any interop issue.

/Stefan

Den 2022-01-12 kl. 00:57, skrev Ryan Sleevi:
> The issue here is one of backwards compatibility, and has been
> discussed several times in the past, such
> as https://mailarchive.ietf.org/arch/msg/pkix/nWgnNZHh2w2l-WfbHKozpm2IWcQ/
> and https://mailarchive.ietf.org/arch/msg/pkix/3Rg8ChXgvcmvSlM10ECDI7c2Dik/
>
> There is no compatibility issue with the CA/Browser Forum documents,
> which address what CAs can do, so this is primarily one with ETSI.
>
> There are immediately available technical solutions for ETSI that do
> not introduce the interoperability concerns that redefining 5280 would
> requirements on the vetting of that information and its source,
> nothing prevents the use of a distinct Attribute Type and Value within
> an ETSI OID arc to convey that information as suitable.
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 Jan 2022 10:45:24 +0100

Den 2022-01-12 kl. 09:55, skrev Stefan Santesson:
> reason what so ever to defend that limitation. I have used 64+
> attribute values in certs forever and never seen any interop issue.

I want to correct myself.

I meant to delete the sentence above, because it is too strong, but it
got sent by mistake. In truth, I can't be certain that there are no
consequences of lifting the 64 character size limit. But I would be
surprised if any serious implementation relies on that limitation from
RFC 5280.

The reason is simply that no certificate has a label saying "I'm a RFC
5280 cert". All certificate using applications will see is a X.509
certificate. The same is true for attributes. There is no label in the
attribute announcing that it is a RFC5280 attribute version of an X.520
attribute. The cert simply holds an attribute that identifies itself as
an X.520 attribute. Reasonable implementations should be able to expect
that they comply with the X.520 definition of that attribute since it
has an X.520 OID.

Various protocols and applications may create profiles within the
boundaries of underlying standards. That is OK. CAB forum may provide
its limitations and ETSI may provide theirs. But the basic standards and
their ASN.1 modules should not be in conflict. It is inherently BAD to
have RFC 5280 and X.520 with conflicting definition of the same
attribute OID:s.

I think it is much more reasonable that CAB forum or any other
application or protocol that need these limitations, to define such
limitations in their profile, and not to rely on conflicting ASN.1 modules.

/Stefan

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 12 Jan 2022 08:12:10 -0500

On Wed, Jan 12, 2022 at 3:55 AM Stefan Santesson <[email-masked]> wrote:

> Ryan,
>
> I have to shamefully admit that my skills in English is not good enough to
> decode your message with certainty. Despite reading it over and over.
>
> Are you actually suggesting that the ETSI standards should move away from
> using X.520 attributes (that actually are defined without size limitations
> since 2008) and define copies of these attributes under ETSI OID arc being
> an exact copy of the current X.520 definition of the same attributes?
>
That is what I suggest, and precisely how the standards were defined to
support.

There is zero technical or policy reason to use the X.520 attributes. We do
not have an X.500 directory, the distinguishedName is not subject to a
global naming authority, and the extensibility afforded wholly avoids the
issue of incompatibility with the ASN.1 modules previously published.

This is no different than the other lessons that this WG, and industry,
have learned, such as those related to the params of AlgorithmIdentifiers
or to changing the module definition of extensions: you simply assign a new
OID for your new version and move on.

Can you please elaborate what technical need exists to use the X.520
attribute, particularly since the function of the modern X.509
Subject/Issuer is simply to serve as a pseudo-random unique value, rather
than reflect a global DIT?

> defined by IETF. They are defined by ITU X.520. ITU updated them in 2008 to
> lift the 64 character limitation. RFC 5280 is not up to date on this
To avoid needing to rehash past argument and discussion, perhaps it would
be worth reviewing those previous discussions I shared. I, and I suspect
others, are familiar with the “cause” of the divergence, but I do hope you
can read those past messages to understand the incompatibility.

I realize, from those past conversations, that your present position
appears to remain unchanged. That is unfortunate that the real world of
deployed software has not swayed you otherwise, but that is why I also
offered solutions that would address this issue without causing
comparability or interop problem.

When faced with a solution that needlessly causes backwards comparability
issue, versus a solution that is fully aligned with both existing software
and the specifications, I hope we can find some agreement on taking the
sensible path.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 Jan 2022 16:56:42 +0100

Ryan,

Very interesting discussion, but unfortunately off-topic.

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

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?

/Stefan

Den 2022-01-12 kl. 14:12, skrev Ryan Sleevi:
>     I have to shamefully admit that my skills in English is not good
>     enough to decode your message with certainty. Despite reading it
>     over and over.
>
>     Are you actually suggesting that the ETSI standards should move
>     away from using X.520 attributes (that actually are defined
>     without size limitations since 2008) and define copies of these
>     attributes under ETSI OID arc being an exact copy of the current
>     X.520 definition of the same attributes?
>
> That is what I suggest, and precisely how the standards were defined
> to support.
>
> There is zero technical or policy reason to use the X.520 attributes.
> We do not have an X.500 directory, the distinguishedName is not
> subject to a global naming authority, and the extensibility afforded
> wholly avoids the issue of incompatibility with the ASN.1 modules
> previously published.
>
> This is no different than the other lessons that this WG, and
> industry, have learned, such as those related to the params of
> AlgorithmIdentifiers or to changing the module definition of
> extensions: you simply assign a new OID for your new version and move on.
>
> Subject/Issuer is simply to serve as a pseudo-random unique value,
> rather than reflect a global DIT?
>
>     The problem here is that the attributes referred to in RFC 5280
>     are not defined by IETF. They are defined by ITU X.520. ITU
>     updated them in 2008 to lift the 64 character limitation. RFC 5280
>     is not up to date on this matter. As simple as that.
>
> To avoid needing to rehash past argument and discussion, perhaps it
> would be worth reviewing those previous discussions I shared. I, and I
> suspect others, are familiar with the “cause” of the divergence, but I
> do hope you can read those past messages to understand the
> incompatibility.
>
> appears to remain unchanged. That is unfortunate that the real world
> of deployed software has not swayed you otherwise, but that is why I
> also offered solutions that would address this issue without causing
> When faced with a solution that needlessly causes backwards
> comparability issue, versus a solution that is fully aligned with both
> existing software and the specifications, I hope we can find some
> agreement on taking the sensible path.
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Jan 2022 11:03:21 -0500

Ryan:

> Oh, no, I was trying to convey that the relevant ETSI specifications already introduce a number of extensions that require updating software. So if the concern is that "Software needs to be updated to display a friendly ETSI name for this OID from ETSI's arc", and that's seen as a reason against such a simple change, then it doesn't hold up, because "Software needs to be updated to display other ETSI qualified attributes".
> 
> Basically, the choice is "compatibility issue for existing software" or "updates for new software for better display", and the latter seems eminently preferable and entirely reasonable. This is why we have OIDs that can be assigned in AttributeTypeAndValues.

I think the actual incompatibility problem was introduced when X.509 was changed.

In particular, the naming attributes used to be defined as:

  DirectoryString{INTEGER:maxSize} ::= CHOICE {
      teletexString    TeletexString(SIZE (1..maxSize)),
      printableString  PrintableString(SIZE (1..maxSize)),
      bmpString        BMPString(SIZE (1..maxSize)),
      universalString  UniversalString(SIZE (1..maxSize)),
      uTF8String       UTF8String(SIZE (1..maxSize))  }

Then, without changing the OIDs for the naming attributes, the definition became:

  UnboundedDirectoryString ::= CHOICE {
     teletexString    TeletexString(SIZE (1..MAX)),
     printableString  PrintableString(SIZE (1..MAX)),
     bmpString        BMPString(SIZE (1..MAX)),
     universalString  UniversalString(SIZE (1..MAX)),
     uTF8String       UTF8String(SIZE (1..MAX)) }

The definition used in RFC 5280 will be accepted by implementations that use DirectoryString or UnboundedDirectoryString.  However, implementations that use UnboundedDirectoryString can produce certificates that will fail to decode in an implementation of RFC 5280.

In short, we may already be in a place where implementations conforming to X.509 will produce a certificate that cannot be decoded by an implementation that conforms to RFC 5280.  This was understood in 2017 when this topic was discussed on the PKIX WG mail list.

Russ

---

From: Peter Bowen <[email-masked]>
Date: Wed, 12 Jan 2022 08:26:08 -0800

> In short, we may already be in a place where implementations conforming to X.509 will produce a certificate that cannot be decoded by an implementation that conforms to RFC 5280.  This was understo…

There may also be divergence due to the fact that RFC 5280 says "The
profiles are presented in the 1988 Abstract Syntax Notation One
(ASN.1) rather than the 1997 ASN.1 syntax used in the most recent
ISO/IEC/ITU-T standards."  The content of teletexString being
different in ASN.1 from 1988.  In ASN.1 editions other than 1988,
teletexString used character set 6 (which is the same as the first 127
characters of Unicode), but in 1988 it used character set 2.  In
character set 6, 0x24 and 0x7E are respectively $ and ~, but these
characters are not included in character set 2.  The same variation
also applies to IA5String - in ASN.1 from 1988, it cannot contain $ or
~, which is very relevant. to URI-type subject alternative names.

It would not surprise me if X.509 (2019) Corrigendum 1 (10/21), X.520
(10/19), X.501 (2019) Amendment 1 (10/21), and other joint ITU-T, ISO,
and IEC standards have further deviation from RFC 5280.

Thanks,
Peter

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 12 Jan 2022 12:00:30 -0500

> 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.

> 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.

> 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.

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 12 Jan 2022 12:08:23 -0500

> I think the actual incompatibility problem was introduced when X.509 was
<snip>
> In short, we may already be in a place where implementations conforming to
> X.509 will produce a certificate that cannot be decoded by an
> implementation that conforms to RFC 5280.  This was understood in 2017 when
> this topic was discussed on the PKIX WG mail list.
>

Oh, we're in complete agreement, as hopefully my most recent message to
Stefan clarifies. As X.682 highlights, the constraint is part of the type.
When X.509/X.520 changed the constraint, understandably to better align
with LDAP/X.500, they fundamentally altered the type. Just like using two
different types with an extension is a recipe for incompatibility, so too
is using two different types within a name. While it was still called the
same thing, it represents a different abstract type - and, as a
consequence, creates incompatibilities based on which module you use, since
the types now differ.

For those not familiar with this subtlety, X.680 I.1 provides a useful
overview of how the type tree works, and particularly, Table I.1 is useful
for understanding about how this change in X.509/X.520 was incompatible
with ASN.1 module definitions. Specifically, to be considered an extension
type, rather than a new type, changes to constraints can only be
added/extended, not altered.

---

From: Rob Stradling <[email-masked]>
Date: Wed, 12 Jan 2022 17:42:56 +0000

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 <[email-masked]> on behalf of Ryan Sleevi <[email-masked]>
Sent: 12 January 2022 17:00
To: Stefan Santesson <[email-masked]>
Cc: Roman Danyliw <[email-masked]>; Ryan Sleevi <[email-masked]>; Russ Housley <[email-masked]>; Limited Additional Mechanisms for PKIX and SMIME Discussion List <[email-masked]>; Benjamin Kaduk <[email-masked]>; Tim Hollebeek <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Ryan,

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.

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.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 12 Jan 2022 20:49:41 +0100

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

The way you create a narrow profile is by applying constraints on the
data object that is defined in the standard being profiled.

That is, in this case you would use to ASN.1 definition of the
authoritative standard, but say that for implementations of this
profile, you MUST limit names to 64 characters.

To use a different syntax is not to profile at all.

Basically I agree to a lot of what you say, and I don't defend the
actions of ITU or in particular the choices of ETSI. But that is not the
issue. The issue is still that how much we may dislike it, the OID of
these attributes are under ITU change control. We already have a
potential interop issue. I'm not convinced that we have a real interop
issue as I suspect that practically no implementations break if served a
name with more than 64 characters. If you know one that breaks, it would
be really great to get that information!

I'm trying to be pragmatic and figure out the least evil alternative.

/Stefan

---

From: Peter Bowen <[email-masked]>
Date: Wed, 12 Jan 2022 11:59:31 -0800

On Wed, Jan 12, 2022 at 11:49 AM Stefan Santesson <[email-masked]> wrote:
> Basically I agree to a lot of what you say, and I don't defend the actions of ITU or in particular the choices of ETSI. But that is not the issue. The issue is still that how much we may dislike it, the OID of these attributes are under ITU change control. We already have a potential interop issue.

I think that this exposes the core question: from an IETF document
perspective, is the view that they are (a) under ITU change control or
(b) did the IETF fork with the creation of RFC2459 and now there are
two separate definitions of the meaning of an attribute with OID
2.5.4.3 - one if you follow IETF specs and one if you follow ITU-T
specs?

> I'm not convinced that we have a real interop issue as I suspect that practically no implementations break if served a name with more than 64 characters. If you know one that breaks, it would be really great to get that information!

Thanks,
Peter

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Jan 2022 16:27:50 -0500

> On Jan 12, 2022, at 2:59 PM, Peter Bowen <[email-masked]> wrote:
> 

It is a profile of X.509.  As far as I can see, it is still a profile.

In my view, don't put a string in this field that is longer that 64 characters is a profile.  I further believe this is a profile because an implementation of X.509 (after the addition of UnboundedDirectoryString) will accept certificates and CRLs generated by an implementation of RFC 5280.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Jan 2022 16:34:52 -0500

> On Jan 12, 2022, at 11:26 AM, Peter Bowen <[email-masked]> wrote:
> 

This is not an issue because RFC 5280 says:

   The DirectoryString type is defined as a choice of PrintableString,
   TeletexString, BMPString, UTF8String, and UniversalString.  CAs
   conforming to this profile MUST use either the PrintableString or
   UTF8String encoding of DirectoryString, with two exceptions.  When
   CAs have previously issued certificates with issuer fields with
   attributes encoded using TeletexString, BMPString, or
   UniversalString, then the CA MAY continue to use these encodings of
   the DirectoryString to preserve backward compatibility.  Also, new
   CAs that are added to a domain where existing CAs issue certificates
   with issuer fields with attributes encoded using TeletexString,
   BMPString, or UniversalString MAY encode attributes that they share
   with the existing CAs using the same encodings as the existing CAs
   use.

So, the only reason that TeletexString might appear is to preserve backward compatibility, whihc means the same bits on the wire.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 12 Jan 2022 16:47:01 -0500

Historical note:  the change in the structure was before RFC 2459 was published.  The basic constraints and the name constraints were put in two different extensions in order to keep basic constraints very simple (one might say, to keep them basic).  At the time, the PKIX WG was developing the initial profile based on draft versions of X.509v3.  Both X.509v3 and the I-D were moving, and there was feedback flowing in both directions.  I think it was a success.

Russ

> On Jan 12, 2022, at 12:42 PM, Rob Stradling <[email-masked]> wrote:
> 
> Ryan wrote:
> https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ipki-part1-01#section-4.2.6 <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.
> 
> > curl -s https://lapo.it/asn1js/oids.js <https://lapo.it/asn1js/oids.js> | grep basicConstraints
> From: Spasm <[email-masked] <mailto:[email-masked]>> on behalf of Ryan Sleevi <[email-masked] <mailto:[email-masked]>>
> To: Stefan Santesson <[email-masked] <mailto:[email-masked]>>
> Cc: Roman Danyliw <[email-masked] <mailto:[email-masked]>>; Ryan Sleevi <[email-masked] <mailto:[email-masked]>>; Russ Housley <[email-masked] <mailto:[email-masked]>>; Limited Additional Mechanisms for PKIX and SMIME Discussion List <[email-masked] <mailto:[email-masked]>>; Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>; Tim Hollebeek <[email-masked] <mailto:[email-masked]>>
> On Wed, Jan 12, 2022 at 10:56 AM Stefan Santesson <[email-masked] <mailto:[email-masked]>> wrote:
> Ryan,
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: Peter Bowen <[email-masked]>
Date: Wed, 12 Jan 2022 15:54:07 -0800

On Wed, Jan 12, 2022 at 1:34 PM Russ Housley <[email-masked]> wrote:
> So, the only reason that TeletexString might appear is to preserve backward compatibility, which means the same bits on the wire.

I went back and checked again, and TeletexString is actually safe.  It
is character set 102 in all editions of BER/DER.

Unfortunately the issue about character set varying by edition of
BER/DER applies to IA5String and VisibleString (plus VideotexString,
GraphicString, and GeneralString which are not used in RFC 5280).
Compare Table 2 in X.209 (1988), Table 3 in X.690 (1997), and Table 3
in X.690 (2015).

Thanks,
Peter

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 13 Jan 2022 09:12:49 +0000

________________________________
From: Spasm <[email-masked]> on behalf of Peter Bowen <[email-masked]>
Sent: Wednesday, January 12, 2022 8:59 PM

On Wed, Jan 12, 2022 at 11:49 AM Stefan Santesson <[email-masked]> wrote:
> Basically I agree to a lot of what you say, and I don't defend the actions of ITU or in particular the choices of ETSI. But that is not the issue. The issue is still that how
> much we may dislike it, the OID of these attributes are under ITU change control. We already have a potential interop issue.

> I'm not convinced that we have a real interop issue as I suspect that practically no implementations break if served a name with more than 64 characters. If you
> know one that breaks, it would be really great to get that information!

Coming from my world I agree, we don't develop with ASN.1 modules in Java, C#, Go, Rust, Python, C/C++, etc. I read the old threads though and there were people who still use ASN.1 compilers. My guess mostly for embedded systems? Of course we need to consider legacy systems, but we also need to find a way to move forward keeping the great things that RFC2459->3280->5280 has brought to the world.

RFC5280 is probably the most inflential standard apart from X.509 itself contributing to the success of PKI and how actually interoperable it is globally. There are profiles of IETF specs, including RFC5280 for industry use cases such as ETSI, CA/B Forum, 3GPP, ERMTS, ICAO, etc. But in general, they specify RFC5280 as base, making some exceptions. Even if we here know here that there is no "strict" RFC5280 compliance enforcement out there (and we don't want it), users writing tenders, procurements, other technical specifications believe that there is and this causes issues and wastes resources. The more the rest of the world deviates from RFC5280 the worse it will get (i.e. more work for me). I would hate to see that RFC5280, and/or -bis, becomes less relevant and superseded by hundreds of small variations and profiles. RFC5280 has served us remarkably well, and I would like to see that continue in the future. I believe it serves us all best.

In my humble opinion there should probably be an RFC5280-bis someday, gathering the deviations from places like CA/B Forum, ETSI, etc. Legacy applications can continue for years to mandate RFC5280 in their eco systems. RFC5280-bis should of course be as backwards compatible as possible, but remove some limitations that is starting to cause work arounds, which in turn negatively affects interoperability. It is much better for interoperability that profiles put limits on the base spec, than expand on the base spec. It's my uneducated guess on IETF processes of course that a -bis is the best way to achieve this.

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 13 Jan 2022 11:03:49 +0100

Let me remind you that ITU-T (and ISI/IEC JTC 1/SC6) removed the length
restriction on attribute types, as LDAP does not have length restriction on
its attribute type definitions. It was done to solve a compatibility issue
with LDAP. Two groups within IETF have conflicting specifications for length
restrictions for attribute types. This is due to lack of coordination within
IETF and therefore an IETF issue and not an X.509 issue.

Best regards,

Erik

Fra: Spasm <[email-masked]> På vegne af Tomas Gustavsson
Sendt: 13 January 2022 10:13
Til: Peter Bowen <[email-masked]>; Stefan Santesson <[email-masked]>
Cc: Roman Danyliw <[email-masked]>; Ryan Sleevi <[email-masked]>; Russ
Housley <[email-masked]>; Limited Additional Mechanisms for PKIX and
SMIME Discussion List <[email-masked]>; Rob Stradling <[email-masked]>;
Benjamin Kaduk <[email-masked]>; Tim Hollebeek <[email-masked]>
Emne: Re: [lamps] New Liaison Statement, "Liaison statement to IETF on RFC
5280 attribute length limitations"

  _____  

From: Spasm <[email-masked] <mailto:[email-masked]> > on
behalf of Peter Bowen <[email-masked] <mailto:[email-masked]> >
Sent: Wednesday, January 12, 2022 8:59 PM

On Wed, Jan 12, 2022 at 11:49 AM Stefan Santesson <[email-masked]
<mailto:[email-masked]> > wrote:
> Basically I agree to a lot of what you say, and I don't defend the actions
of ITU or in particular the choices of ETSI. But that is not the issue. The
issue is still that how 

> much we may dislike it, the OID of these attributes are under ITU change
control. We already have a potential interop issue.

> I'm not convinced that we have a real interop issue as I suspect that
practically no implementations break if served a name with more than 64
characters. If you 

> know one that breaks, it would be really great to get that information!

Coming from my world I agree, we don't develop with ASN.1 modules in Java,
C#, Go, Rust, Python, C/C++, etc. I read the old threads though and there
were people who still use ASN.1 compilers. My guess mostly for embedded
systems? Of course we need to consider legacy systems, but we also need to
find a way to move forward keeping the great things that RFC2459->3280->5280
has brought to the world. 

RFC5280 is probably the most inflential standard apart from X.509 itself
contributing to the success of PKI and how actually interoperable it is
globally. There are profiles of IETF specs, including RFC5280 for industry
use cases such as ETSI, CA/B Forum, 3GPP, ERMTS, ICAO, etc. But in general,
they specify RFC5280 as base, making some exceptions. Even if we here know
here that there is no "strict" RFC5280 compliance enforcement out there (and
we don't want it), users writing tenders, procurements, other technical
specifications believe that there is and this causes issues and wastes
resources. The more the rest of the world deviates from RFC5280 the worse it
will get (i.e. more work for me). I would hate to see that RFC5280, and/or
-bis, becomes less relevant and superseded by hundreds of small variations
and profiles. RFC5280 has served us remarkably well, and I would like to see
that continue in the future. I believe it serves us all best.

In my humble opinion there should probably be an RFC5280-bis someday,
gathering the deviations from places like CA/B Forum, ETSI, etc. Legacy
applications can continue for years to mandate RFC5280 in their eco systems.
RFC5280-bis should of course be as backwards compatible as possible, but
remove some limitations that is starting to cause work arounds, which in
turn negatively affects interoperability. It is much better for
interoperability that profiles put limits on the base spec, than expand on
the base spec. It's my uneducated guess on IETF processes of course that a
-bis is the best way to achieve this.

---

From: Corey Bonnell <[email-masked]>
Date: Thu, 13 Jan 2022 12:57:33 +0000

Hi Peter,
> Unfortunately the issue about character set varying by edition of BER/DER
applies to IA5String and VisibleString (plus VideotexString, GraphicString,
and GeneralString which are not used in RFC 5280). Compare Table 2 in X.209
(1988), Table 3 in X.690 (1997), and Table 3 in X.690 (2015).

As you noted in a previous email, IA5String is used for the
uniformResourceIdentifier GeneralName. Additionally, it also used for the
emailAddress attribute and rfc822Name GeneralName, so the inability to
encode "$" and "~" in these elements would pose a potentially significant
interoperability issue, especially since the local-part of email addresses
may contain "$" or "~" (as specified in RFC 2822, section 3.2.4 for the
"atext" ABNF production rule).

After some digging, it does appear that Character Set 2 includes the
currency symbol (2/4, or 0x24) and "overline" (7/15, or 0x7e) in its
repertoire. Given that these character codes are defined in the character
set, I believe any deviation between IA5String as defined in X.208/209
(1988) and later versions would only manifest in differences with visual
display and does not constitute a restriction on the encoding for the
IA5String type as used in RFC 5280. The same would apply for VisibleString.

Thanks,
Corey

-----Original Message-----
From: Spasm <[email-masked] <mailto:[email-masked]> > On
Behalf Of Peter Bowen
Sent: Wednesday, January 12, 2022 6:54 PM
To: Russ Housley <[email-masked] <mailto:[email-masked]> >
Cc: Ryan Sleevi <[email-masked] <mailto:[email-masked]> >; SPASM
<[email-masked] <mailto:[email-masked]> >
Subject: Re: [lamps] New Liaison Statement, "Liaison statement to IETF on
RFC 5280 attribute length limitations"

On Wed, Jan 12, 2022 at 1:34 PM Russ Housley <[email-masked]
<mailto:[email-masked]> > wrote:
>
> > On Jan 12, 2022, at 11:26 AM, Peter Bowen <[email-masked]
<mailto:[email-masked]> > wrote:
> > teletexString used character set 6 (which is the same as the first 
> > 127 characters of Unicode), but in 1988 it used character set 2.  In 
> > also applies to IA5String - in ASN.1 from 1988, it cannot contain $ 
> > or ~, which is very relevant. to URI-type subject alternative names.
> >
> > It would not surprise me if X.509 (2019) Corrigendum 1 (10/21), 
> > X.520 (10/19), X.501 (2019) Amendment 1 (10/21), and other joint 
> > ITU-T, ISO, and IEC standards have further deviation from RFC 5280.
>
> So, the only reason that TeletexString might appear is to preserve
backward compatibility, which means the same bits on the wire.

I went back and checked again, and TeletexString is actually safe.  It is
character set 102 in all editions of BER/DER.

Unfortunately the issue about character set varying by edition of BER/DER
applies to IA5String and VisibleString (plus VideotexString, GraphicString,
and GeneralString which are not used in RFC 5280).
Compare Table 2 in X.209 (1988), Table 3 in X.690 (1997), and Table 3 in
X.690 (2015).

Thanks,
Peter

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 13 Jan 2022 09:56:57 -0500

On Thu, Jan 13, 2022 at 5:04 AM Erik Andersen <[email-masked]> wrote:

> with LDAP. Two groups within IETF have conflicting specifications for
> length restrictions for attribute types. This is due to lack of
> coordination within IETF and therefore an IETF issue and not an X.509 issue.
>

Hi Eric,

I totally appreciate your continued engagement here, and I hope my attempt
to explain the root cause does not come across as a blameful postmortem.
However, I'm not sure your conclusions are correct here, and it seems we
may want to sort things out.

I think you're entirely correct for highlighting that there was a
disconnect between LDAP and PKIX with respect to these attributes, and that
would, in turn, make it difficult to encode an LDAP distinguished name
within the PKIX profile of distinguished names. While this is arguably not
the main mode of using PKIX certificates for most folks, I also don't
discount that it's also a non-trivial amount of certificates, particularly
in products like Microsoft Active Directory, which marry the two very
closely. So please understand that what follows is not meant to discount
that there is/was an incompatibility.

However, I think we need to look at the "solution" that ITU-T/X.509 adopted.

Do you agree or disagree that the constraints make up an indelible part of
the type, as described in X.682? If there's some disagreement here about
constraints being part of the type, we should definitely dive into this
first, and you can stop reading here.

If we accept that different constraints represent different abstract types
(even if some of those may be extension types of a base type), then the
approach X.509 took is to redefine a type, without changing an OID.
Hopefully we can agree that X.509 redefined the type, if we've agreed so
far, adopting the LDAP definition rather than the X.509/PKIX definition.

I think it's generally understood that we don't redefine types within
versions of ASN.1 modules to be incompatible. While some specifications
may, they minimally introduce those new types in a new module definition,
and the wire protocol itself needs to then negotiate which module version
it's using. This is not the use of the 'version' field of a certificate
(which ties to the X.680 extensibility model, as discussed in RFC 5912),
but rather, separate protocol negotiations. Obviously, that's a heavy lift,
and recognizing that, I think we'd agree that X.509 left in ample
extensibility points within X.509v3 to avoid the need for such issues. This
is both through the 'extensibility implied' (prosaically referred to in
Appendix B of RFC 5280, although not explicitly stated in the module) and
the use of IDENTIFIED BY and information classes (in 5912) and the prosaic
restrictions (in 5280, due to the limits of 1988 syntax) to provide
extension points for things to change. As previously mentioned, if an
extension were to syntactically change in a way not permitted by ASN.1's
extensibility rules, there's hopefully uncontroversial understanding that
we'd assign a new extension OID to reflect the new syntax and potentially
new semantics.

If we look back with hindsight, which I realize may be seen as unfair, when
it was recognized that LDAP and PKIX were not 1:1 interchangable among the
distinguishedName, an alternative solution, which adhered to these
principles, would have been to define a translation function between them.
Whether that translation function was executed on the client in possession
of a given certificate, attempting an LDAP server query, or on the LDAP
server itself, quietly transforming the query and mapping attributes, seems
mostly irrelevant, as either/both would have worked. I specifically mean
the defining of a new set of attributes, with new OIDs and no length
restrictions, to express the unbounded lengths of an LDAP distinguished
name within PKIX, and a mapping/identity function to relate that to the
"classic" LDAP fields.

That may seem like "too much work", but recall that PKIX already has such
mapping functions, and has had the concept since more or less its beginning
within the IETF. For example, the mapping of domainComponents to construct
DNS names, or, within RFC 5280, the mapping of character spaces using
StringPrep to account for IDNs. The concept of mapping values between two
different protocols/systems is not foreign, nor rare, for certificate using
systems.

I can totally appreciate that this may not have been obvious to ITU-T,
given that X.509 was intended to be intrinsically linked to X.500, while
PKIX (particularly Section 2.1 of RFC 5280) made it quite explicit that
this coupling was neither intended nor necessary. However, I hope we can
agree that the above solution would have been fully compatible with the
constraints and goals of ASN.1, and would have been fully consistent with
existing practice.

While we can't go and change the past for X.509, I hope we can recognize
that PKIX doesn't need to make that same mistake. The use of a
transformation function to address ETSI's needs seems entirely reasonable,
if such interoperability is needed, although given my understanding of ETSI
ESI's experiences in this space, they don't even need to have LDAP
interchange, they just want to express the attributes in a well-defined way
that it is interoperable among ETSI ESI-specifications implementations.
Defining new attributes alone is an entirely reasonable step, and if LDAP
integration is further desired, then writing a specification for how to
transform an X.509 distinguishedName into an LDAP distinguishedName equally
seems not unreasonable. Within LDAP server implementations, this is not at
all unheard of, with many servers supporting computed attributes (i.e. the
value of one field is dynamically sourced from another), also sometimes
referred to as "constructed" attributes. [1][2][3]

I raise this to highlight that we have solutions, other than adopting the
X.509 redefinition of the ASN.1 module in a backwards-incompatible way, to
solve the problem. That seems worthwhile to explore?

[1] https://ldapwiki.com/wiki/Constructed%20Attribute
[2]
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/a3aff238-5f0e-4eec-8598-0a59c30ecd56
[3]
https://docs.oracle.com/middleware/11119/oid/administer/computed_attr.htm

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 13 Jan 2022 15:27:15 +0000

________________________________
From: Ryan Sleevi <[email-masked]>
Sent: Thursday, January 13, 2022 2:40 PM
Subject: Re: [lamps] New Liaison Statement, "Liaison statement to IETF on RFC 5280 attribute length limitations"

On Thu, Jan 13, 2022 at 4:12 AM Tomas Gustavsson <[email-masked]<mailto:[email-masked]>> wrote:

Coming from my world I agree, we don't develop with ASN.1 modules in Java, C#, Go, Rust, Python, C/C++, etc.

What do you use to implement the specifications? Or do the implementations in your world ignore the constraints on the type?

I think your reply may have conflated the use of an ASN.1 compiler - which will generally produce code that correctly implements the specification for the type - as being the only code that will correctly implement the specification. While it’s certainly true that several popular libraries incorrectly ignore portions of RFC 5280, such as constraints, they also tend to ignore X.680 in significant ways, such as sorting of SETs or default value encoding, as to create interoperability issues. Given the constraint is fundamentally part of the type specification, it sounds like you’re saying the software being used may be buggy and selectively ignoring portions of the specification?

It is perhaps telling that one of the most popular tools to verify CA compliance with the specifications and their business contracts with root programs makes use of an ASN.1 parser/compiler to generate a significant amount validation logic, and how many issues have been detected because of it.

I’m not trying to take cheap shots here, but highlighting that the “It doesn’t break in product X”, because product X doesn’t enforce these limits, is often also because product X is incorrectly implementing a variety of other elements and contributing generally to interoperability issues, by nature of the hand-rolling. So while it’s true that changing the limit won’t create interoperability issues for such software, it’s frequently because said software has already introduced a number of other interoperability issues (on the encoder side) or security issues (on the decoder side), due to the lack of use of a compiler.

I started answering the technical questions, but I deleted that. The point I tried to say was not about "It doesn’t break in product X", so I don't want to go down that rabbit hole. I've played with several different APIs, Peter likely much more than I have.
The point I tried to make is that RFC5280 is more than the ASN.1 modules. It's a technical and semi-technical specification of rules supporting a large amount of different use cases, and it has been amazingly successful in that. There are hiccups, but the world have hiccups and RFC5280 have less than many others. As the use cases evolve so must RFC5280, as it has evolved in the past from RFC2459. Perhaps it's kicking in open doors but I want to show my support for evolving RFC5280, for the next 15 years.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 13 Jan 2022 08:40:50 -0500

On Thu, Jan 13, 2022 at 4:12 AM Tomas Gustavsson <
[email-masked]> wrote:

> C#, Go, Rust, Python, C/C++, etc.
>

What do you use to implement the specifications? Or do the implementations
in your world ignore the constraints on the type?

I think your reply may have conflated the use of an ASN.1 compiler - which
will generally produce code that correctly implements the specification for
the type - as being the only code that will correctly implement the
specification. While it’s certainly true that several popular libraries
incorrectly ignore portions of RFC 5280, such as constraints, they also
tend to ignore X.680 in significant ways, such as sorting of SETs or
default value encoding, as to create interoperability issues. Given the
constraint is fundamentally part of the type specification, it sounds like
you’re saying the software being used may be buggy and selectively ignoring
portions of the specification?

It is perhaps telling that one of the most popular tools to verify CA
compliance with the specifications and their business contracts with root
programs makes use of an ASN.1 parser/compiler to generate a significant
amount validation logic, and how many issues have been detected because of
it.

I’m not trying to take cheap shots here, but highlighting that the “It
doesn’t break in product X”, because product X doesn’t enforce these
limits, is often also because product X is incorrectly implementing a
variety of other elements and contributing generally to interoperability
issues, by nature of the hand-rolling. So while it’s true that changing the
limit won’t create interoperability issues for such software, it’s
frequently because said software has already introduced a number of other
interoperability issues (on the encoder side) or security issues (on the
decoder side), due to the lack of use of a compiler.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 13 Jan 2022 19:50:20 +0100

Implementers makes deviations from standards where the standards impose
unrealistic constraints that prevents the standards from serve its purpose.

In theory, that should never happen. In practice it happens all the
time. Mostly for one big reason. When we have to choose between being
faithful to a standard or to our customers an to our business, we choose
the latter over the former.

When I worked for Microsoft and was responsible for Microsoft and MS
CAPI conformance to RFC 5280, we had a couple of known deviations that
we told IETF openly about. Correcting them would simply either break
customers badly or would break our own PKI.

The old length limitations of common attributes is one such unrealistic
constraints. I have worked with PKI implementations for almost 30 years,
and I have yet to come across a single basic PKI library that enforce
this limitation when decoding cert attributes. I have yet to create one
application based on PKI that enforce these constraints.

If CAB forum and web PKI for some reason want to keep this constraint
for web PKI, then fine. But they will never achieve this by relying on
the underlying PKI library to do it for them. Bouncycastle won't do it,
OpenSSL won't do it and I challenge you to find one that does. So I bet
you have to do it in your implementation anyway and therefore this
limitation would be better to write in the CAB forum certificate profile
if they need it.

To highlight how ridiculous and how US centric and arrogant this
limitation is, keep in mind that the limitation is applied to the number
of bytes and not the number of characters. Only if you are English and
use US ASCII will you get 64 characters. If your name use some other
alphabet like Arabic, Greek or any other legitimate character set not
composed of US ASCII, you will typically just get 32 characters using
UTF-8, and that it not much to work with.

The unfortunate consequence of keeping unrealistic limitations that no
base implementation honours, is that it encourages a culture where
implementers deviate from RFC 5280, simply because they have to to get
the job done.

This is not meant to be criticism of any individual, so please do not
take offence. This is just my own honest assessment.

I used to ba a standards fundamentalist, but decades of trying to
implement these standards has humbled me and mad me more pragmatic.

But I have very little hope you will agree with me :)

Cheers

/Stefan

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 13 Jan 2022 15:00:08 -0500

> unrealistic constraints that prevents the standards from serve its purpose.

I think it's important to highlight the distinction between
*intentional* deviations
and *unintentional* deviations. While I agree and recognize your point
regarding intentionality, I would go as far as to suggest that many of the
deviations seen in practice are unintentional and serve no purpose other
than harming interoperability. I do not think, for example, that the DER
encoding of default values is something one would reasonably be comfortable
arguing is an intentional deviation.

> application based on PKI that enforce these constraints.

I believe what you're saying here is you don't have experience with
applications that use the ASN.1 modules, and instead hand-implement
encoders/decoders, is that correct? I'm familiar that was Microsoft's
historic approach, and was similarly marred by a legacy of negative
reputation due to high-security issues in msasn1.dll, but I think both the
culture there, and more broadly in the industry, has changed and recognized
that such approaches are not exactly worthwhile.

I have worked with dozens of systems, primarily closed source, that work
based on ASN.1 modules and generate code based on those modules. I suspect
many folks on this list have more than a passing familiarity with such
systems, not the least of which because they're actively highlighted by the
ITU-T themselves, at https://www.itu.int/en/ITU-T/asn1/Pages/Tools.aspx

Are you saying we should ignore such systems?

> UTF-8, and that it not much to work with.

Could you highlight where you believe this to be the case? I think this may
be an example of the danger of handrolling decoders, since it's easy to
overlook the specifications emphasize that limits are expressed not in
bytes, as you assert, but characters. Appendix A.1 of RFC 5280 does make
sure to highlight this, but I acknowledge, this has been a source of
misinterpretation in the past by some.

I'm not trying to argue for "standards fundamentalism". I'm trying to argue
against needlessly creating backwards compatibility issues, especially
those long-understood and explicitly flagged by specifications, when
readily present, well-understood, and well-established alternatives exist.
There doesn't seem to be a response on the substance of the concerns or
compatibility, just a personal view that it's not important, and while
that's an important perspective to consider, doesn't seem to demonstrate an
appreciation for the concerns or the awareness of the ecosystem situation
that would be impacted.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 13 Jan 2022 23:13:36 +0100

Den 2022-01-13 kl. 21:00, skrev Ryan Sleevi:
> Could you highlight where you believe this to be the case? I think
> this may be an example of the danger of handrolling decoders, since
> it's easy to overlook the specifications emphasize that limits are
> expressed not in bytes, as you assert, but characters. Appendix A.1 of
> RFC 5280 does make sure to highlight this, but I acknowledge, this has
> been a source of misinterpretation in the past by some.

Ryan,

I stand corrected. I falsely assumed that OpenSSL had this figured out
in the way they apply size constraints to certificate creation. I found
the correct definition in X.680 and RFC 5280 is correct as you point out
that size limitation on string types applies to the number of characters.

So it's not as bad as OpenSSL made me believe tat it is. But it is still
bad :)

I stand by my conclusions and other observations. Just adding as
response to your other comment that it is still possible to use a
compiler even if you make selective deviations. One way is to just edit
the ASN.1 you feed to your compiler. In the end of the day, I have yet
to see any publicly available tool that enforce these size constraints
when decoding X.509 certs. Until one is found that matters, there are no
backwards compatibility issues by aligning with X.520.

If anyone know of such tool/library that would be broken, please let us
know.

/Stefan

---

From: Carl Wallace <[email-masked]>
Date: Thu, 13 Jan 2022 17:40:59 -0500

From: Spasm <[email-masked]> on behalf of Stefan Santesson <[email-masked]>
Organization: 3xA Security AB
Date: Thursday, January 13, 2022 at 5:13 PM
To: Ryan Sleevi <[email-masked]>
Cc: Limited Additional Mechanisms for PKIX and SMIME Discussion List <[email-masked]>
Subject: Re: [lamps] New Liaison Statement, "Liaison statement to IETF on RFC 5280 attribute length limitations"

Could you highlight where you believe this to be the case? I think this may be an example of the danger of handrolling decoders, since it's easy to overlook the specifications emphasize that limits are expressed not in bytes, as you assert, but characters. Appendix A.1 of RFC 5280 does make sure to highlight this, but I acknowledge, this has been a source of misinterpretation in the past by some.

Ryan,

I stand corrected. I falsely assumed that OpenSSL had this figured out in the way they apply size constraints to certificate creation. I found the correct definition in X.680 and RFC 5280 is correct as you point out that size limitation on string types applies to the number of characters.

So it's not as bad as OpenSSL made me believe tat it is. But it is still bad :)

I stand by my conclusions and other observations. Just adding as response to your other comment that it is still possible to use a compiler even if you make selective deviations. One way is to just edit the ASN.1 you feed to your compiler. In the end of the day, I have yet to see any publicly available tool that enforce these size constraints when decoding X.509 certs. Until one is found that matters, there are no backwards compatibility issues by aligning with X.520.

[CW] Are you the arbiter of what matters? Is there an IANA registry for that? Re: your earlier comments, this has never been a question of doing right by your customer or pursuing standards purity. It’s a question of taking a shortcut or doing the work to make changes in a community friendly way. Had available extensibility methods been employed in 2008, which I think is when you suggested this dis-alignment occurred, it’d likely be well established by now. Re: editing ASN.1 files, a primary reason that folks edit ASN.1 files is to dance around mis-encodings in the wild. To see that practice cited here in support of this action is pretty funny. In my view, the specs are like a big band chart we are all playing. When the trumpet section just decides to play a different key or tempo mid-tune, the overall suffers. 

If anyone know of such tool/library that would be broken, please let us know.

/Stefan

_______________________________________________ Spasm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Fri, 14 Jan 2022 10:45:39 -0500

> If anyone know of such tool/library that would be broken, please let us know.

The modules for pyasn1 certainly enforce the size limitations in RFC 5280.  I have no idea how much relying party code uses this library to decode certificates.

https://github.com/etingof/pyasn1-modules/blob/master/pyasn1_modules/rfc5280.py

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Jan 2022 15:38:42 -0500

My assessment is that there is not consensus to removal of the upper-bound size limits on naming attributes in RFC 5280 as requested by ETSI.  However, there is not objection to the specification of new naming attribute object identifiers for naming attributes without upper-bound size limits.  Any disagreement?

Russ

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Jan 2022 20:40:47 +0000

>     My assessment is that there is not consensus to removal of the upper-bound size limits on naming attributes in RFC 5280 as requested by ETSI.  However, there is not objection to the specificati…

I agree with this.

I am concerned about deployed software making assumptions on max length and then getting a security vulnerability or worse.

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 25 Jan 2022 09:13:26 +0000

I object to creating new naming attribute object identifiers, especially shadowing existing ones.
Albeit there is nothing technically preventing it in private communities, my experience tells me that it is very much detrimental to interoperability, security and efficiency. I'd rather not see it in RFCs, or encouraged. There is way too much effort spent already on detail issues with existing attributes and new attributes invented in other communities.

Regards,
Tomas

________________________________
From: Spasm <[email-masked]> on behalf of Salz, Rich <rsalz=[email-masked]>
Sent: Monday, January 24, 2022 9:40 PM
To: Russ Housley <[email-masked]>; LAMPS <[email-masked]>
Cc: Roman D. Danyliw <[email-masked]>; Tim Hollebeek <[email-masked]>; Ben Kaduk <[email-masked]>
Subject: Re: [lamps] New Liaison Statement, "Liaison statement to IETF on RFC 5280 attribute length limitations"

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [email-masked] with any questions.

I agree with this.

_______________________________________________
Spasm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Ctomas.gustavsson%40keyfactor.com%7C094477e03cd541ef583208d9df79d876%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637786536751260456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=YYRM6A9bsyMarFCjpAiFP4wcDXdtQR%2FzXhe6RlQDhrE%3D&amp;reserved=0

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 25 Jan 2022 11:42:04 +0100

Hi,

Yes, allow me to strongly agree to what Tomas writes here.

I didn't respond to the suggestion to issue new OID:s for shadow
attributes because I didn't even see it as a serious suggestion, but
simply a spiced argument that is obviously not realistic.

In theory, PKI is not locked on specific attributes as we can introduce
any attribute with any OID. But in practice, that ship sailed long ago.
In fact it sailed decades ago. Today we have tons of specifications and
tools and even standards, that has been locked on the standard X.520
attribute set. What makes this even worse is that the common structure
of certificate policies, that arised from the IETF RFC 2527, certificate
profile was part of what needs to go into a policy. The result of that
is that the ETSI policies for EU certificates on which the whole EU
legal framework is funded, there is a dependency on the certificate
profile ETSI EN 319 412-2, which in turn is locked on the X.520
attribute set.

Other common tools like Open SSL use common abbreviations like CN, C, O,
OU in their API:s to issue and process certificates. These are locked on
the standard X.520 attributes.

So NO. Issuing new OIDs for the X.520 attributes is not a serious
alternative that have any chance of becoming a reality in wide
deployment. Any attempt to do so will be as widely ignored as the size
limitations we discuss now are ignored today.

My conclusion is that no one has demonstrated any software on a generic
level (like PKI libraries) that fails or crashes in the presence of too
long names. It is quite obvious why that is the case. If they did, they
would crash very fast, because this limitation is so widely ignored,
that any attempt to enforce them on a generic level (all X.509 certs
regardless of usage or purpose), would render the software unusable.

I have a distinct feeling that this debate is not about fact or reason.
It is about pride and ITU vs IETF. The ITU did a bad thing, so here at
IETF we don't like to just accept that. So we are going to uphold an
unrealistic limitation that the world will keep ignoring.

So be it.

/Stefan

Den 2022-01-25 kl. 10:13, skrev Tomas Gustavsson:
> Albeit there is nothing technically preventing it in private
> communities, my experience tells me that it is very much detrimental
> to interoperability, security and efficiency. I'd rather not see it in
> RFCs, or encouraged. There is way too much effort spent already on
> detail issues with existing attributes and new attributes invented in
> other communities.
>
> Regards,
> Tomas
>
> ------------------------------------------------------------------------
> *From:* Spasm <[email-masked]> on behalf of Salz, Rich
> <rsalz=[email-masked]>
> *Sent:* Monday, January 24, 2022 9:40 PM
> *To:* Russ Housley <[email-masked]>; LAMPS <[email-masked]>
> *Cc:* Roman D. Danyliw <[email-masked]>; Tim Hollebeek
> <[email-masked]>; Ben Kaduk <[email-masked]>
> *Subject:* Re: [lamps] New Liaison Statement, "Liaison statement to
> IETF on RFC 5280 attribute length limitations"
>  
> CAUTION: External Sender - Be cautious when clicking links or opening
> attachments. Please email [email-masked] with any questions.
>
>
> >     My assessment is that there is not consensus to removal of the
> upper-bound size limits on naming attributes in RFC 5280 as requested
> by ETSI.  However, there is not objection to the specification of new
> naming attribute object identifiers for naming attributes without
> upper-bound size limits.  Any disagreement?
>
> I agree with this.
>
> I am concerned about deployed software making assumptions on max
> length and then getting a security vulnerability or worse.
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Ctomas.gustavsson%40keyfactor.com%7C094477e03cd541ef583208d9df79d876%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637786536751260456%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=YYRM6A9bsyMarFCjpAiFP4wcDXdtQR%2FzXhe6RlQDhrE%3D&amp;reserved=0>
>

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 25 Jan 2022 10:45:26 -0500

On Tue, Jan 25, 2022 at 5:42 AM Stefan Santesson <[email-masked]> wrote:

> attributes because I didn't even see it as a serious suggestion, but simply
> a spiced argument that is obviously not realistic.
>
>
> any attribute with any OID. But in practice, that ship sailed long ago. In
> fact it sailed decades ago. Today we have tons of specifications and tools
> and even standards, that has been locked on the standard X.520 attribute
> set. What makes this even worse is that the common structure of certificate
> policies, that arised from the IETF RFC 2527, certificate profile was part
> of what needs to go into a policy. The result of that is that the ETSI
> policies for EU certificates on which the whole EU legal framework is
> funded, there is a dependency on the certificate profile ETSI EN 319 412-2,
> which in turn is locked on the X.520 attribute set.
>
Hi Stefan,

I'm not sure what technical argument is being made here, can you elaborate?
That is, can you explain what it means "sailed decades ago"? Is there
software you're aware of that does not support OIDs outside of a fixed set,
and which needs to interoperate with these?

I can understand something being "inconvenient", in the sense it's not the
first choice, but I'm not sure what technical compatibility argument is
being made here. Further inline.

> the standard X.520 attributes.
I'm not sure I understand this objection? In the case of the existing ETSI
specifications, ETSI both uses non-standard attributes already - from the
organizationIdentifier to the CA/Browser Forum's
jurisdictionOfIncorporation - and these have not demonstrated any
compatibility issues. Further, the ETSI specifications for validation
require that the CA validate and construct this information somewhat
independently, so if you're making an argument that this is an issue for
CSR production, I hope you can see that's not the case.

It sounds like this might be a "developer ergonomics" question, but many
existing tools, including OpenSSL, provide an easy way for users to
associate an OID with a "shortname" and "longname", as you describe here.
E.g. for OpenSSL, it's as simple as an OID file within the config, which
can be updated by users or common distributions.

So again, I'm not sure the technical argument being made here, especially
in light of ample evidence that contradicts what appears to be the claims
and conclusions.

> would crash very fast, because this limitation is so widely ignored, that
> any attempt to enforce them on a generic level (all X.509 certs regardless
> of usage or purpose), would render the software unusable.
>
It seems the goalposts have been moved here. The claim - which is
indisputable and responded to you multiple times - is that such a change is
a new ASN.1 module that is wire-incompatible with the previous ASN.1
module. Any decoder using the previous ASN.1 module cannot decode such
certificates, full stop. Unless the proposal is for the IETF to re-open
PKIX, revise the ASN.1 module, and then revise every specification that
references RFC 3280 and RFC 5280 to reflect this new RFC, then I don't see
how this is at all a reasonable or considered solution. For what it's
worth, that's the exact step that the ITU-T had to take when making this
change: Any document referring to the previous modules needed to be updated
(typically, by uprev'ing the dependency on X.501). Previous implementations
*cannot* decode the new certificates.

Are these facts in dispute? Or is this exactly what you're arguing - that
protocols such as TLS 1.2 and TLS 1.3 need to be revised, with new versions
(that are distinct from previous versions) be introduced, to ensure the new
module dependency, as the ITU did?

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 25 Jan 2022 17:22:32 +0000

Hi Ryan,

For me I don't understand exactly what you mean with decoders. I think there is a difference between what you specify as "decoder using the previous ASN.1 module" and "Previous implementations", compared to what Stefan denotes as "software on a generic level (like PKI libraries)".

Can you help me understand this difference with a real world example?

I made the 5 minutes test with an O of 121 characters, which should violate RFC5280 definition of ub-organization-name-length INTEGER ::= 64

In OpenJDK 11.0.13 keytool it displays:
Owner: C=SE, O=TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest, CN=localhost

On OpenSSL 1.1.f it displays:
Subject: CN = localhost, O = TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest, C = SE

I deployed it to a JBoss server as a TLS server certificate. I have screenshots from both Firefox and Chromium how they display the field well, and the TLS 1.2 connection work (I don't want to send images to the list).

Regards,
Tomas

________________________________
From: Ryan Sleevi <[email-masked]>
Sent: Tuesday, January 25, 2022 4:45 PM
To: Stefan Santesson <[email-masked]>
Cc: Tomas Gustavsson <[email-masked]>; Salz, Rich <rsalz=[email-masked]>; Russ Housley <[email-masked]>; LAMPS <[email-masked]>; Roman D. Danyliw <[email-masked]>; Tim Hollebeek <[email-masked]>; Ben Kaduk <[email-masked]>
Subject: Re: [lamps] New Liaison Statement, "Liaison statement to IETF on RFC 5280 attribute length limitations"

On Tue, Jan 25, 2022 at 5:42 AM Stefan Santesson <[email-masked]<mailto:[email-masked]>> wrote:

I didn't respond to the suggestion to issue new OID:s for shadow attributes because I didn't even see it as a serious suggestion, but simply a spiced argument that is obviously not realistic.

In theory, PKI is not locked on specific attributes as we can introduce any attribute with any OID. But in practice, that ship sailed long ago. In fact it sailed decades ago. Today we have tons of specifications and tools and even standards, that has been locked on the standard X.520 attribute set. What makes this even worse is that the common structure of certificate policies, that arised from the IETF RFC 2527, certificate profile was part of what needs to go into a policy. The result of that is that the ETSI policies for EU certificates on which the whole EU legal framework is funded, there is a dependency on the certificate profile ETSI EN 319 412-2, which in turn is locked on the X.520 attribute set.

Hi Stefan,

I'm not sure what technical argument is being made here, can you elaborate? That is, can you explain what it means "sailed decades ago"? Is there software you're aware of that does not support OIDs outside of a fixed set, and which needs to interoperate with these?

I can understand something being "inconvenient", in the sense it's not the first choice, but I'm not sure what technical compatibility argument is being made here. Further inline.

Other common tools like Open SSL use common abbreviations like CN, C, O, OU in their API:s to issue and process certificates. These are locked on the standard X.520 attributes.

I'm not sure I understand this objection? In the case of the existing ETSI specifications, ETSI both uses non-standard attributes already - from the organizationIdentifier to the CA/Browser Forum's jurisdictionOfIncorporation - and these have not demonstrated any compatibility issues. Further, the ETSI specifications for validation require that the CA validate and construct this information somewhat independently, so if you're making an argument that this is an issue for CSR production, I hope you can see that's not the case.

It sounds like this might be a "developer ergonomics" question, but many existing tools, including OpenSSL, provide an easy way for users to associate an OID with a "shortname" and "longname", as you describe here. E.g. for OpenSSL, it's as simple as an OID file within the config, which can be updated by users or common distributions.

So again, I'm not sure the technical argument being made here, especially in light of ample evidence that contradicts what appears to be the claims and conclusions.

My conclusion is that no one has demonstrated any software on a generic level (like PKI libraries) that fails or crashes in the presence of too long names. It is quite obvious why that is the case. If they did, they would crash very fast, because this limitation is so widely ignored, that any attempt to enforce them on a generic level (all X.509 certs regardless of usage or purpose), would render the software unusable.

It seems the goalposts have been moved here. The claim - which is indisputable and responded to you multiple times - is that such a change is a new ASN.1 module that is wire-incompatible with the previous ASN.1 module. Any decoder using the previous ASN.1 module cannot decode such certificates, full stop. Unless the proposal is for the IETF to re-open PKIX, revise the ASN.1 module, and then revise every specification that references RFC 3280 and RFC 5280 to reflect this new RFC, then I don't see how this is at all a reasonable or considered solution. For what it's worth, that's the exact step that the ITU-T had to take when making this change: Any document referring to the previous modules needed to be updated (typically, by uprev'ing the dependency on X.501). Previous implementations cannot decode the new certificates.

Are these facts in dispute? Or is this exactly what you're arguing - that protocols such as TLS 1.2 and TLS 1.3 need to be revised, with new versions (that are distinct from previous versions) be introduced, to ensure the new module dependency, as the ITU did?

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 25 Jan 2022 17:46:03 +0000

Sorry, I realized that my test was not complex. Since my email was about new OIDs not about lengths. Here is a new test with ETSI organizationIdentifier (no I don't like that either) and a more rare Tax ID Number (I wasn't too thrilled to have to implement this technically in backend and UI).

OpenJDK 11.0.13 keytool:
Owner: C=SE, O=TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest, OID.2.5.4.97=OrgIdentifier, CN=localhost, OID.1.3.6.1.4.1.18838.1.1=Text ID number

OpenSSL 1.1.f:
Subject: 1.3.6.1.4.1.18838.1.1 = Text ID number, CN = localhost, organizationIdentifier = OrgIdentifier, O = TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest, C = SE

It works as TLS server certificate. Both Firefox and Chromium displays the custom OIDs in a bad way. Firefox displays the values, but only blank for the OIDs it does not have labels for. Chromium does not display the custom OIDs as all, but it does show a field that is not present in the certificate (OU).

The only thing this test shows is that neither length not custom OIDs blocks these common applications from working technically. Custom OIDs are a bigger issue for Usability, UI, than length. Therefore I am still against promoting custom OIDs in Subject and Issuer DNs.

Regards,
Tomas
________________________________
From: Spasm <[email-masked]> on behalf of Tomas Gustavsson <[email-masked]>
Sent: Tuesday, January 25, 2022 6:22 PM
To: Ryan Sleevi <[email-masked]>; Stefan Santesson <[email-masked]>
Cc: Roman D. Danyliw <[email-masked]>; Salz, Rich <rsalz=[email-masked]>; Russ Housley <[email-masked]>; LAMPS <[email-masked]>; Tim Hollebeek <[email-masked]>; Ben Kaduk <[email-masked]>
Subject: Re: [lamps] New Liaison Statement, "Liaison statement to IETF on RFC 5280 attribute length limitations"

Hi Ryan,

Regards,
Tomas

Hi Stefan,

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 25 Jan 2022 17:53:24 +0000

Another correction.

Chromium: In the General certificate view tab, it shows nothing of the custom OID, in the Details tab it does show "OID.2.5.4.97 = OrgIdentifier" and "OID.1.3.6.1.4.1.18838.1.1 = Text ID number"

Sent: Tuesday, January 25, 2022 6:46 PM

OpenJDK 11.0.13 keytool:

OpenSSL 1.1.f:

Regards,
Tomas

Hi Ryan,

Regards,
Tomas

Hi Stefan,

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 25 Jan 2022 13:01:18 -0500

On Tue, Jan 25, 2022 at 12:46 PM Tomas Gustavsson <
[email-masked]> wrote:

> It works as TLS server certificate. Both Firefox and Chromium displays the
> custom OIDs in a bad way. Firefox displays the values, but only blank for
> the OIDs it does not have labels for. Chromium does not display the custom
> OIDs as all, but it does show a field that is not present in the
> certificate (OU).
>
> The only thing this test shows is that neither length not custom OIDs
> blocks these common applications from working technically. Custom OIDs are
> a bigger issue for Usability, UI, than length. Therefore I am still against
> promoting custom OIDs in Subject and Issuer DNs.
>

I think you've highlighted here an important detail:

The opposition to using attributes, as defined in the specifications, seems
to not be a question of technical interoperability or correctness, but a
desire about particular user interfaces in particular products, and wanting
to influence those. How does that square with the objectives set out by RFC
5280, Section 2? This seems to be an incompatible requirement, on its face,
but also, a poor reason to justify technical interoperability.

To the question from your previous message:

> For me I don't understand exactly what you mean with decoders

It's simple. Anyone who implements a certificate parser/decoder using the
pseudo-ASN.1 (88) of RFC 2459, the subsequent modules in RFC 3280/5280, or
the ASN.1 (2002 syntax) of RFC 5912, will be unable to decode such
certificates. Russ has already pointed out an example open-source
implementation, although this equally applies to any application that uses
https://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx

I realize that some products opt to roll hand decoders or encoders, and
frequently, fail to implement things correctly. I'm sure we're all familiar
with variations of "encoded DEFAULT values", "un-ordered SETs", or
"misencoded parameters" - I know we've seen it in CA software. Indeed, it's
perhaps telling that one of the most important certificate linting tools
generates its code from the RFC 3280/5280 modules directly, to try to
detect such failures to adhere to the specification.

Any change to the module to remove the constraints is wire-incompatible
with these tools, and will fail to decode, because it will violate the
ASN.1 constraint. The ASN.1 constraint is as much as part of the type
definition as is a BOOLEAN versus an INTEGER vs a BIT STRING - they are
core to the abstract type, and violations are decode failures.

I understand that the proponents would like to make this a "popularity
contest", for which any implementation (e.g. any tool using asn1.c) is
discredited as "not important", but it seems as a first order, we need to
see if we can agree on that basic statement:

1. To remove the length limits means introducing a new version of PKIX with
a new ASN.1 module
2. That new module will be wire incompatible with any decoder that
implements the existing module correctly
3. Because it is a new ASN.1 module, any specifications/protocols within
the IETF that depend on RFC 3280/5280 (which share modules) will need to be
updated to refer to PKIX-bis
4. Because it is wire incompatible, any of these specifications/protocols
will also need to uprev their versions, to indicate they're negotiating the
new module.

This is the process that ITU-T took. Even if we agreed to do 3, which is a
heavy lift, doing 4 is a recipe for interop disaster.

If we disagree on 1 and 2, then let's discuss, because that's hopefully
been demonstrated by now. If we disagree on 4 being necessary, please
outline what the proposed plan is.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 25 Jan 2022 19:01:59 +0100

Thanks for the information Tomas.

This is very much in line with my experiences from doing PKI related
implementations for many many years.

However, allow me to set one thing straight. organizationIdentifier is
NOT an ETSI attribute. It is an X.520 attribute.

id-at-organizationIdentifier              OBJECT IDENTIFIER ::= {id-at 97}

organizationIdentifier ATTRIBUTE ::= {
  WITH SYNTAX              UnboundedDirectoryString
  EQUALITY MATCHING RULE   caseIgnoreMatch
  SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
  SINGLE VALUE             TRUE
  LDAP-SYNTAX              directoryString.&id
  LDAP-NAME                {"organizationIdentifier"}
  ID                       id-at-organizationIdentifier }

The fact that this attribute was created by ITU long ago (with full
collaboration with IETF at the time may I add), and it still is so hard
to get it recognized, demonstrates exactly how hard it is to introduce
new attributes in the PKI area. This is not caused by the X.509 standard
itself, but caused by how all the tools, standards and specifications
were made, and still are.

Which is why solving this with new attributes is so unrealistic.
Demonstrated

/Stefan

Den 2022-01-25 kl. 18:46, skrev Tomas Gustavsson:
> Sorry, I realized that my test was not complex. Since my email was
> about new OIDs not about lengths. Here is a new test with ETSI
> organizationIdentifier (no I don't like that either) and a more rare
> Tax ID Number (I wasn't too thrilled to have to implement this
> technically in backend and UI).
>
> OpenJDK 11.0.13 keytool:
> Owner: C=SE,
> O=TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest,
> OID.2.5.4.97=OrgIdentifier, CN=localhost,
> OID.1.3.6.1.4.1.18838.1.1=Text ID number
>
> OpenSSL 1.1.f:
> Subject: 1.3.6.1.4.1.18838.1.1 = Text ID number, CN = localhost,
> organizationIdentifier = OrgIdentifier, O =
> TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest,
> C = SE
>
> It works as TLS server certificate. Both Firefox and Chromium displays
> the custom OIDs in a bad way. Firefox displays the values, but only
> blank for the OIDs it does not have labels for. Chromium does not
> display the custom OIDs as all, but it does show a field that is not
> present in the certificate (OU).
>
> blocks these common applications from working technically. Custom OIDs
> are a bigger issue for Usability, UI, than length. Therefore I am
> still against promoting custom OIDs in Subject and Issuer DNs.
>
> Regards,
> Tomas
> *From:* Spasm <[email-masked]> on behalf of Tomas Gustavsson
> <[email-masked]>
> *Sent:* Tuesday, January 25, 2022 6:22 PM
> *To:* Ryan Sleevi <[email-masked]>; Stefan Santesson
> <[email-masked]>
> *Cc:* Roman D. Danyliw <[email-masked]>; Salz, Rich
> <rsalz=[email-masked]>; Russ Housley
> <[email-masked]>; LAMPS <[email-masked]>; Tim Hollebeek
> For me I don't understand exactly what you mean with decoders. I think
> there is a difference between what you specify as "decoder using the
> previous ASN.1 module" and "Previous implementations", compared to
> what Stefan denotes as "software on a generic level (like PKI libraries)".
>
> I made the 5 minutes test with an O of 121 characters, which should
> violate RFC5280 definition of ub-organization-name-length INTEGER ::= 64
>
> Owner: C=SE,
> O=TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest,
> CN=localhost
>
> Subject: CN = localhost, O =
> TestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTestTest,
> C = SE
>
> I deployed it to a JBoss server as a TLS server certificate. I have
> screenshots from both Firefox and Chromium how they display the field
> well, and the TLS 1.2 connection work (I don't want to send images to
> the list).
>
> Regards,
> Tomas
>
> *From:* Ryan Sleevi <[email-masked]>
> *Sent:* Tuesday, January 25, 2022 4:45 PM
> *To:* Stefan Santesson <[email-masked]>
> *Cc:* Tomas Gustavsson <[email-masked]>; Salz, Rich
> <rsalz=[email-masked]>; Russ Housley
> <[email-masked]>; LAMPS <[email-masked]>; Roman D. Danyliw
> <[email-masked]>; Tim Hollebeek <[email-masked]>; Ben Kaduk
> <[email-masked]>
>     attributes because I didn't even see it as a serious suggestion,
>     but simply a spiced argument that is obviously not realistic.
>
>
>     In theory, PKI is not locked on specific attributes as we can
>     introduce any attribute with any OID. But in practice, that ship
>     sailed long ago. In fact it sailed decades ago. Today we have tons
>     of specifications and tools and even standards, that has been
>     locked on the standard X.520 attribute set. What makes this even
>     worse is that the common structure of certificate policies, that
>     arised from the IETF RFC 2527, certificate profile was part of
>     what needs to go into a policy. The result of that is that the
>     ETSI policies for EU certificates on which the whole EU legal
>     framework is funded, there is a dependency on the certificate
> I'm not sure what technical argument is being made here, can you
> elaborate? That is, can you explain what it means "sailed decades
> ago"? Is there software you're aware of that does not support OIDs
> outside of a fixed set, and which needs to interoperate with these?
>
> I can understand something being "inconvenient", in the sense it's not
> the first choice, but I'm not sure what technical compatibility
> argument is being made here. Further inline.
>
>     Other common tools like Open SSL use common abbreviations like CN,
>     C, O, OU in their API:s to issue and process certificates. These
>     are locked on the standard X.520 attributes.
>
> I'm not sure I understand this objection? In the case of the existing
> ETSI specifications, ETSI both uses non-standard attributes already -
> from the organizationIdentifier to the CA/Browser Forum's
> independently, so if you're making an argument that this is an issue
> for CSR production, I hope you can see that's not the case.
>
> It sounds like this might be a "developer ergonomics" question, but
> many existing tools, including OpenSSL, provide an easy way for users
> to associate an OID with a "shortname" and "longname", as you describe
> here. E.g. for OpenSSL, it's as simple as an OID file within the
> config, which can be updated by users or common distributions.
>
> So again, I'm not sure the technical argument being made here,
> especially in light of ample evidence that contradicts what appears to
> be the claims and conclusions.
>
>     My conclusion is that no one has demonstrated any software on a
>     generic level (like PKI libraries) that fails or crashes in the
>     presence of too long names. It is quite obvious why that is the
>     case. If they did, they would crash very fast, because this
>     limitation is so widely ignored, that any attempt to enforce them
>     on a generic level (all X.509 certs regardless of usage or
>     purpose), would render the software unusable.
>
> indisputable and responded to you multiple times - is that such a
> change is a new ASN.1 module that is wire-incompatible with the
> previous ASN.1 module. Any decoder using the previous ASN.1 module
> cannot decode such certificates, full stop. Unless the proposal is for
> the IETF to re-open PKIX, revise the ASN.1 module, and then revise
> every specification that references RFC 3280 and RFC 5280 to reflect
> this new RFC, then I don't see how this is at all a reasonable or
> considered solution. For what it's worth, that's the exact step that
> the ITU-T had to take when making this change: Any document referring
> to the previous modules needed to be updated (typically, by uprev'ing
> the dependency on X.501). Previous implementations /cannot/ decode the
> new certificates.
>
> Are these facts in dispute? Or is this exactly what you're arguing -
> that protocols such as TLS 1.2 and TLS 1.3 need to be revised, with
> new versions (that are distinct from previous versions) be introduced,
> to ensure the new module dependency, as the ITU did?
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Jan 2022 18:02:40 +0000

The current 5280 ASN.1 module has SIZE qualifiers in it.  These are defines that show up like “ub-common-name”, such as this at https://www.rfc-editor.org/rfc/rfc5280.html#page-124
                ub-common-name INTEGER ::= 64

Ryan is making the point that if you change those values, or otherwise modify the SIZE qualifiers, you are no longer wire-compatible with what is in 5280. He, and I, and perhaps others, have pointed out that there could well be existing deployed code that would reject, or crash, or CVE, if  they were given data that exceeded those constraints.

So far, the only response I have seen (including Tomas’s note, to which this is a reply) says “nobody followed those limits anyway, you’re just being (er) pedantic, we can change them and nothing will break.”

I disagree.  Those *are* the limits. You can’t just change them because you find the limit, well, limiting. It could break things, and asking for an example to “prove” that there will be breakage misses the point. Now, people might not like the limits, and someone even said that the IETF is playing non-technical games to “show itself up” over the ITU-T, but that’s not fair. We’re just insisting that the rules for a published standard be followed. If you want to change *just* the IETF RFC 5280 to increase the SIZE values, you can try: write a draft, bring it to SECDISPATCH and see what happens.

Can you create new OID’s with a larger SIZE value?  Sure. There might be varying degrees of difficulty and/or display, as shown by Tomas’s second note. Being able to add new attributes is not a MUST in 5280, but rather RECOMMENDED. All of the existing defined attributes have a SIZE qualifier, BTW.

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 25 Jan 2022 18:30:33 +0000

Thanks, my goal was to demonstrate how bad custom OIDs is for interoperability, and object to the statement "there is not objection to the specification of new naming attribute object identifiers for naming attributes without upper-bound size limits".

A process question, If there is ever an RFC 9280, would it be possible or desirable to do changes such as length limits there, or including new OIDs for that matter?

________________________________
From: Salz, Rich <[email-masked]>
Sent: Tuesday, January 25, 2022 7:02 PM
To: Tomas Gustavsson <[email-masked]>; Ryan Sleevi <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: Re: [lamps] New Liaison Statement, "Liaison statement to IETF on RFC 5280 attribute length limitations"

The current 5280 ASN.1 module has SIZE qualifiers in it.  These are defines that show up like “ub-common-name”, such as this at https://www.rfc-editor.org/rfc/rfc5280.html#page-124<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc5280.html%23page-124&data=04%7C01%7CTomas.Gustavsson%40keyfactor.com%7C1d34721550134c1687c508d9e02ce5c6%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637787305722168718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=IyY0LPc7I%2FR5wae%2Bc2CXaQeZ553n%2BahBQgRXX14p%2B5o%3D&reserved=0>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Jan 2022 18:34:09 +0000

*   A process question, If there is ever an RFC 9280, would it be possible or desirable to do changes such as length limits there, or including new OIDs for that matter?

That would be up to the people proposing the group, the IESG’s views, the approved charter, and those who show up to the WG meetings.

So: yes.  Or no. :)

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 25 Jan 2022 20:12:10 +0100

Den 2022-01-25 kl. 19:02, skrev Salz, Rich:
> I disagree.  Those **are** the limits. You can’t just change them
> because you find the limit, well, limiting. It could break things, and
> asking for an example to “prove” that there will be breakage misses
> the point.

Let's not forget that these attributes do not have size limits!

These attributes are not defined by IETF. They are defined by ITU and
the ITU removed the size limits.

It's just the IETF profile that has size limits.

So any implementation of X.509 must account for the possibility that
these ITU attributes may exceed the RFC 5280 profile size limits.

This typically applies to all basic PKI libraries, who can't assume that
all users implements RFC 5280.

If it hadn't been for this fact, I would totally support your position.
Now we need to choose the least evil. My choice is to be pragmatic about
it.

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 25 Jan 2022 14:12:06 -0500

On Tue, Jan 25, 2022 at 1:30 PM Tomas Gustavsson <
[email-masked]> wrote:

> Thanks, my goal was to demonstrate how bad custom OIDs is for
> interoperability, and object to the statement "there is not objection to
> the specification of new naming attribute object identifiers for naming
> attributes without upper-bound size limits".
>

With respect to interoperability, just to make sure: This isn't about
technical interoperability, correct?

This is solely with respect to user-interface design considerations when
such attributes are used and the distinguished name is presented to the
end-user?

I don't know that we'd normally refer to that as an interoperability
concern, and so I'm wanting to make sure I'm not overlooking any points
being made here.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Jan 2022 19:14:49 +0000

*   These attributes are not defined by IETF. They are defined by ITU and the ITU removed the size limits.
  *   It's just the IETF profile that has size limits.

Is there a freely-available spec that I can read to understand this?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Jan 2022 19:17:36 +0000

I already commented on how to propose to change 5280.

  *   So any implementation of X.509 must account for the possibility that these ITU attributes may exceed the RFC 5280 profile size limits.

Well yeah, any software that accepts input MUST be careful about it. :)

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 25 Jan 2022 14:21:34 -0500

On Tue, Jan 25, 2022 at 2:12 PM Stefan Santesson <[email-masked]> wrote:

> I disagree.  Those **are** the limits. You can’t just change them because
> you find the limit, well, limiting. It could break things, and asking for
> an example to “prove” that there will be breakage misses the point.
>
>
> These attributes are not defined by IETF. They are defined by ITU and the
> ITU removed the size limits.
>
I don't believe this reflects the state of the RFCs, similar to the
discussion about characters-vs-bytes.

As captured within RFC 2459, RFC 3280, and RFC 5280, these specifications
define these attributes within the constraint of the RFC's ASN.1 module.
The types defined within X.520 are within a separate module. The RFCs do
not depend on the X.520 module - of any version.

The ITU-T created new versions of its modules (e.g. a new module for
SelectedAttributeTypes in X.520). It then created a new version of
UsefulDefinitions (X.501), that referred to the new SelectedAttributeTypes.
It then required specifications, such as X.509, to refer to the new version
of UsefulDefinitions. And so forth and so forth.

That is, the X.520 version, with the length limit, still exists within a
well-defined ITU-T module with a distinct OID. It co-exists with a version
without length limits, in a separate ITU-T maintained module, also with a
distinct (and different) OID. They aren't wire compatible, so you cannot
mix those two modules.

The IETF RFCs define a third module, and define that type within that
module. It is separate from the ITU-T module, as currently written and
specified. Even if the IETF RFC had imported directly from the ITU-T, it
still would have had to import a specific version of the GlobalIdentifier,
as defined by X.680 (02/2021), 13.9 and 13.12

So even though the ITU-T changed the limits, that would not apply until a
new version of the IETF RFCs are published, referencing that new module.
And then, every specification referencing RFC 3280/5280 would need to be
updated (e.g. to reference 9280). It would not be backwards compatible with
3280/5280, because they're different wire encodings, so every protocol
would need to address it.

That's the request here. The ITU-T specifications have limits. The IETF
specifications replicate those older modules, but do not presently depend
on the ITU-T modules. The request is to use or replicate the newer module,
but that requires a replacement of PKIX and every protocol referencing PKIX
(TLS, IPSec, BGP). That's... a big request. That's why technical
alternatives are being explored.

---

From: Carl Wallace <[email-masked]>
Date: Tue, 25 Jan 2022 14:38:46 -0500

From: Spasm <[email-masked]> on behalf of Stefan Santesson <[email-masked]>
Organization: 3xA Security AB
Date: Tuesday, January 25, 2022 at 5:42 AM
<snip>

I have a distinct feeling that this debate is not about fact or reason. It is about pride and ITU vs IETF. The ITU did a bad thing, so here at IETF we don't like to just accept that. So we are going to uphold an unrealistic limitation that the world will keep ignoring.

[CW] This begs the question, why is it that 5280 is viewed as having to change instead of ITU reverting and defining new attributes with larger limits? I don’t think I’ve seen mention of how ITU became invariant. There’s not an “everyone’s happy” way forward, but undoing the backwards incompatible change and proceeding without breaking backwards compatibility is one possible way forward.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Jan 2022 22:39:25 +0000

*   The IETF RFCs define a third module, and define that type within that module. It is separate from the ITU-T module, as currently written and specified. Even if the IETF RFC had imported directly from the ITU-T, it still would have had to import a specific version of the GlobalIdentifier, as defined by X.680 (02/2021), 13.9 and 13.12

And in fact, the only IMPORT statement is when Sec A.2 (implicitly tagged) does an import of A.1 (explicitly tagged).

Will breaking the SIZE limit work?  Yeah, probably, mostly. Not officially, no guarantees, but “the IETF is not the protocol police.”

  *   That's the request here. The ITU-T specifications have limits. The IETF specifications replicate those older modules, but do not presently depend on the ITU-T modules. The request is to use or replicate the newer module, but that requires a replacement of PKIX and every protocol referencing PKIX (TLS, IPSec, BGP). That's... a big request. That's why technical alternatives are being explored.

Just creating 5280bis would be a horror show, as everyone involved tries to get their “one simple issue” involved.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 26 Jan 2022 15:49:58 +0100

All,

I have through private conversation been made aware that some have felt
disrespected by my arguments in this thread.

I just want to apologize to anyone that have felt that way. That was
absolutely not my intention.

I want to make clear that I respect everyone's opinion and integrity.

/Stefan

---

From: Russ Housley <[email-masked]>
Date: Mon, 31 Jan 2022 16:46:21 -0500

Here is the proposed formal response to the ETSI Liaison Statement.  Please review and offer improvements. if needed.

Russ

= = = = = = 

The LAMPS WG has considered your request to remove the mandatory upper bounds constraints on naming attributes.  The discussion is available on the mail list archive [1].  It is worth noting that this same topic was previously discussed in the PKIX WG in 2015 [2] and 2017 [3].  In all three discussions, the outcome was the same.  There is not consensus for removal of the upper-bound size limits on naming attributes in RFC 5280. 

[1] https://mailarchive.ietf.org/arch/msg/spasm/Ab_sKt_ImC9nNNTU6Lci5Ux4fjY/
[2] https://mailarchive.ietf.org/arch/msg/pkix/3Rg8ChXgvcmvSlM10ECDI7c2Dik/
[3] https://mailarchive.ietf.org/arch/msg/pkix/nWgnNZHh2w2l-WfbHKozpm2IWcQ/ <https://mailarchive.ietf.org/arch/msg/pkix/nWgnNZHh2w2l-WfbHKozpm2IWcQ/>

> On Jan 11, 2022, at 5:47 PM, Liaison Statement Management Tool <[email-masked]> wrote:
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 31 Jan 2022 21:51:16 +0000

*   Here is the proposed formal response to the ETSI Liaison Statement.  Please review and offer improvements. if needed.

Nice archeology. :)  Do you want to say that removing the upper bounds constraints would require re-opening 5280 and that is not work we are willing to take on right now?  I’m perfectly fine with “nope” :)

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 31 Jan 2022 20:18:32 -0500

On Mon, Jan 31, 2022 at 4:51 PM Salz, Rich <rsalz=
[email-masked]> wrote:

>
>    - Here is the proposed formal response to the ETSI Liaison Statement.
>    Please review and offer improvements. if needed.
>
>
>
> Nice archeology. :)  Do you want to say that removing the upper bounds
> constraints would require re-opening 5280 and that is not work we are
> willing to take on right now?  I’m perfectly fine with “nope” :)
>
There was a fourth discussion, back in 2007 when 5280 was still open as
3280bis, in response to
https://datatracker.ietf.org/liaison/376/

That discussion is at
https://mailarchive.ietf.org/arch/msg/pkix/vlYSadaLgdY7R2LYIeBA923fYhs/

There, the decision was made not to further delay 3280bis. There was
suggestion of a fast-follow update at the time, which did not materialize,
and then eventually resulted in the subsequent discussions highlighted by
Russ.

I mention it mostly as an example of previously declining to re-opening
what was then a nearly-finalized 5280. Although the rationale was slightly
different, and perhaps more optimistic, the subsequent discussions helped
codify the risk.

The slides from IETF 70 where this was discussed are
https://www.ietf.org/proceedings/70/slides/pkix-4.pdf and the minutes
https://www.ietf.org/proceedings/70/minutes/pkix.htm which reflect the
consensus shown in the subsequent discussions.