You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
Abstract
Section 2
Section 2.1
Section 4
Section 5.2
The text was updated successfully, but these errors were encountered: