Clarifying the encoding of otherName with BundleEID

[highlunder]

In the table C509 General Names Registry we have included "otherName with BundleEID" with the following value:
eid-structure from RFC 9171

The specification provided in RFC 9171 seems to be more elaborate than the ASN.1 format provided in RFC 9174. We need to clarify which X.509 data that can be expected, and decide how we want to represent it in the target CBOR format.

RFC 9171 (https://www.rfc-editor.org/rfc/rfc9171.html) specifies the eid-structure as follows:

eid-structure = [
uri-code: uint,
SSP: any
]

SSP: [
nodenum: uint,
servicenum: uint
]

More info is given by encoding considerations:
For transmission as a BP endpoint ID, the scheme-specific part of a URI of the dtn scheme SHALL be represented as a CBOR text string unless the EID's SSP is "none", in which case the SSP SHALL be represented as a CBOR unsigned integer with the value zero. For all other purposes, URIs of the dtn scheme are encoded exclusively in US-ASCII characters.

RFC 9174 (https://datatracker.ietf.org/doc/html/rfc9174) specifies BundleEID as follows:

id-on-bundleEID OBJECT IDENTIFIER ::= { id-on 11 }
-- Same encoding as GeneralName of uniformResourceIdentifier
BundleEID ::= IA5String

And gives the following example of a hexadecimal form of the DER encoding of the otherName:

a01c06082b0601050507080ba010160e64746e3a2f2f6578616d706c652f

0 28: [0] {
2 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 11'
12 16: [0] {
14 14: IA5String 'dtn://example/'
: }
: }

[highlunder]

@BrianSipos , the eid-structure otherName addition was added based on your proposal. Do you have input on which use cases that you think should be supported? For instance, in the form of X.509 certificates using the bundleEID?

[BrianSipos]

The otherName form from RFC 9174 was chosen for expediency and compatibility with existing PKIX tools, using the same encoding as the pre-existing URI subjectAlternativeName type.

The eid-structure defined (and used) in RFC 9171 is a scheme-specific compressed representation for numeric URI values using CBOR encoding. Because C509 is using CBOR anyway, this nested CBOR structure fits in well but does require a translation between it and the X.509 text URI form. And a device using the bundleEID will have a CODEC and logic for handling eid-structure anyway becuase it will be handling RFC 9171 bundles.

It would be possible to define the C509 general name as eid-structure / text to allow a 'blind' translation between C509 and X.509 certificates. The text URI encoding of EID is just less efficient and adds more complexity to the C509 user.

[highlunder]

The otherName form from RFC 9174 was chosen for expediency and compatibility with existing PKIX tools, using the same encoding as the pre-existing URI subjectAlternativeName type.

The eid-structure defined (and used) in RFC 9171 is a scheme-specific compressed representation for numeric URI values using CBOR encoding. Because C509 is using CBOR anyway, this nested CBOR structure fits in well but does require a translation between it and the X.509 text URI form.

Thank you for the input! Since we still want to handle the existing X.509 cases, we see potential problems with these conflicting usages. The relatively easy solution would be to clarify that we only support the RFC 9174 case (where BundleEID ::= IA5String), or alternatively drop the specific handling of BundleEID and encode it as a generic otherName (with the value = [ ~oid, bytes ]). Would you still see any benefit in keeping the RFC 9174 style encoding?

[BrianSipos]

I actually see the generic otherName as the place for text-form URI (per RFC 9174) where the size penalty of OID and text URI is no worse than existing X509. The concise CBOR-form of EID (per RFC 9171) would benefit from the concise single-int identifier (as the C509 draft currently states).

So a trivial codec can go back-and-forth between the generic otherName and X509, while an BP-EID-aware codec would use the C509 integer key with the CBOR-form EID value. Would this be helpful to draft as text in the document?

[highlunder]

I actually see the generic otherName as the place for text-form URI (per RFC 9174) where the size penalty of OID and text URI is no worse than existing X509. The concise CBOR-form of EID (per RFC 9171) would benefit from the concise single-int identifier (as the C509 draft currently states).

So a trivial codec can go back-and-forth between the generic otherName and X509, while an BP-EID-aware codec would use the C509 integer key with the CBOR-form EID value. Would this be helpful to draft as text in the document?

A draft text which captures your desired solution(s) would be very useful for us to review!

[BrianSipos]

A question to the authors: does a processor of a C509 cert see the distinction between the two forms of GeneralName, either the specialized (negative codepoint) encoding or the otherName (codepoint zero) encoding?

If so, then the guidance would be for certificate issuers to prefer the "otherName with BundleEID" codepoint -3 if the RFC9171 translation is available and otherwise fall-back to the "otherName" codepoint 0.

It may also be desirable to change the value to "bytes .cbor eid-structure" to make the encoding opaque to those entities that don't understand it. Any thoughts about this?

[highlunder]

If I understand your question correctly: yes following what is currently stated in the draft, a processor of a C509 encoded certificate would either encounter "-3, " for an otherName with BundleEID, or "0, [ ~oid, bytes ]" for a "not further specified" otherName.

Our concern, if we are to keep the "otherName with BundleEID" field, is that we need it to be defined in a non-ambiguous way for translation back to X.509, based on existing defined X.509 ASN.1 structures. Do you have example X.509 certificates which combine id-on-bundleEID with the eid-structure from RFC 9171, and if so, how do they solve the ASN.1 encoding?

[BrianSipos]

The translation in this case, because it uses a compressed form of the URI in a scheme-specific way, requires an implementation to use scheme-specific codecs as registered in the IANA Bundle Protocol URI Scheme Types sub-registry.

I could provide some narrow examples of encoded extensions for X509 and corresponding C509 because I think that would be helpful.

[BrianSipos]

I'm going to make a PR that uses bstr-wrapping of the EID value to make it easier for c509 handlers and add some explanatory text about using the compressed form of the extension vs. the otherName code point 0.

[highlunder]

For us to do: check and review PR #211

[gselander]

@BrianSipos The relation between the X.509 DER encoding and this proposal is not clear to us. Unless this proposal maps to the X.509 encoding it can be considered a future extension but should probably not go into the first version of C509.

[BrianSipos]

That is okay, a generic translator should be able to encode the URI IA5text into the c509 as a generic OID-labeled other name. The compressed form can be deferred and removed from this draft.