Adjust DN regex requirement to be URI requirement

[aj-stein-nist]

Fixes #273 with unclear definition and regex requirements with DN currently in draft.

[SteveLasker]

Calling @CBonnell for some 👀

[CBonnell]

Perhaps I missed it, but what is the motivation of changing to a URI?

[aj-stein-nist]

Perhaps I missed it, but what is the motivation of changing to a URI?

We are specifically customizing the usage of iss in CWT as defined in RFC. In that document, it is a stringOrURI type and it seems like we shifting away from the base usage of URI to something else and with a regex spec I couldn't find in a relevant I-D, RFC, or standards doc that we can normatively cite as a reference.

Is there something I am missing, and is there a valid reference we could use?

[CBonnell]

I agree the current text is not clear, as it doesn't define or reference any regex. However, stating that the iss must be a URI with no further specification is equally unsatisfying.

How about we drop any mandate to use a particular format of iss if the x5t protected header is present? The identity of the issuer will be sourced from the X.509 certificate, so the iss value is largely redundant.

[aj-stein-nist]

I agree the current text is not clear, as it doesn't define or reference any regex. However, stating that the iss must be a URI with no further specification is equally unsatisfying.

There is a little more detail in the CWT RFC and points to the JWT RFC which in turn points to the string representation of URIs RFC. Are those definitions equally unclear?

How about we drop any mandate to use a particular format of iss if the x5t protected header is present? The identity of the issuer will be sourced from the X.509 certificate, so the iss value is largely redundant.

I don't mind that if others have that feedback I'll close this out and start over. That will obsolete the feedback from Hannes that triggered this PR at the same time.

I can bring that on list and reference this discussion.

[CBonnell]

Ah, yes, I forgot to mention: if we want to retain the use of the string representation of the subject DN of the X.509 certificate for the iss value, we can reference RFC 4514.

[aj-stein-nist]

Ah, yes, I forgot to mention: if we want to retain the use of the string representation of the subject DN of the X.509 certificate for the iss value, we can reference RFC 4514.

I can also bring that up as an option on list and adjust accordingly if that is ok.

[CBonnell]

There is a little more detail in the CWT RFC and points to the JWT RFC which in turn points to the string representation of URIs RFC. Are those definitions equally unclear?

I think it’s unclear, as there is no guidance on the content of the iss, only that it is URI-shaped.

[aj-stein-nist]

There is a little more detail in the CWT RFC and points to the JWT RFC which in turn points to the string representation of URIs RFC. Are those definitions equally unclear?

I think it’s unclear, as there is no guidance on the content of the iss, only that it is URI-shaped.

It is similarly unclear to me in the architecture requirements what one should or must do with the DN. It is implied, but left to the implementer to decide for desired X.509 use cases. It is not clear what one should do with it to correctly validate the cert use per the claim, regardless of DN or URI is chosen. Can we both agree that is part of the problem?

[aj-stein-nist]

In any event, I apologize for the delay, I have created the following thread on list to discuss before moving forward with the PR in any significant way. I may stand corrected and others will prefer your approach (which I dubbed Approach #2).

https://mailarchive.ietf.org/arch/msg/scitt/M7G7SrcqXb6P9jU-mLg5VdwvT_g/

[SteveLasker]

Deferring 'till the week of 8/19 as some folks are on vacation.

[achamayou]

I support this change on behalf of the https://github.com/microsoft/CCF project.