Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Carl Wallace's feedback #8

Open
ounsworth opened this issue Apr 25, 2024 · 0 comments
Open

Carl Wallace's feedback #8

ounsworth opened this issue Apr 25, 2024 · 0 comments

Comments

@ounsworth
Copy link
Collaborator

This feedback came on the LAMPS list:
https://mailarchive.ietf.org/arch/msg/spasm/2lAqR2L-PN2JqorFMeCMVlC3Dik/

Below are a few comments following a review of draft-ounsworth-lamps-pq-external-pubkeys-03.

Throughout

  • There are several references to ExternalPublicKey but this is not defined.

Abstract

  • s/transitting/transmitting
  • The mechanism is more like Subject Information Access than Authority Information Access.

Section 2

  • The first paragraph references externalizing signature values, but signatures are not mentioned again. Is the intent for this to be used to sustain externals keys and signatures or only keys? The draft seems to want to be focused on SPKI, so why not just limit to that?
  • Why use GeneralNames here instead of a URI or list of URIs? GeneralName pulls in lots of stuff that is not useful (i.e., ORAddress, EDIPartyName, etc.)

Section 2.1

  • When would parameters ever be used with id-external-value? If never, just say MUST be absent. It may be worth adding some words re: parameters for the hashAlg field as well.
  • What structure should be expected when ExternalValue.location is used somewhere other than SubjectPublicKeyInfo.subjectPublicKey?

Section 4

  • It may be worth adding a privacy consideration re: the need to fetch the public key when using a certificate since this is a change vs. conventional certificates.

Section 5.2

  • The example would be more useful if the external location were publicly accessible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant