Hello Martin, Thank you for your comments! I am not sure if you are aware, but I am going to be handing some editorial changes to this document until publication. I will also try to answer your questions inline.
On Wed, Oct 7, 2020 at 8:26 PM Martin Duke via Datatracker <[email protected]> wrote: > Martin Duke has entered the following ballot position for > draft-ietf-cose-x509-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cose-x509/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I see that it's in the charter as such, but I have no idea why this is > otherwise an Informational RFC, as it extends a Standard RFC and has some > normative language in it for interoperability. > [IP]: From my point of view this has been a decision made during the last rechartering. You can see it in the current charter [1] or this email [2]. One possible reason for that decision is that initially the draft contained hash algorithms as well, which if I understand correctly are usually published in informational drafts. To the best of my knowledge no one has voiced concerns about this document being Informational. If anyone has more context, please chime in. I am not a fan of the passive voice in Section 2: > "Certificates obtained from any of these methods MUST still be validated." > > Who has to validate it? It sounds like we are not requiring constrained > devices > to do this validation, so the document really ought to pin the > responsibility > on the system. > [IP]: My understanding is that the recipient should have enough information to obtain and validate the certificate, while the sender might not have the complete certificate. For example, one possibility is that only part of the certificate chain is sent and the message recipient needs to validate the certificate (possibly using pre-provisioned certificates for building the complete certificate chain), in order to know if it can trust it. Another example is a sender that only has a hash of the certificate along with the private key. In this case the recipient is expected to be able to obtain the correct certificate and validate the message using the appropriate key, probably verifying that the certificate is not revoked, etc. Would the following wording work better for you? Recipients MUST validate the certificate obtained from any of the following four methods. > > > > [1]: https://datatracker.ietf.org/doc/charter-ietf-cose/ [2]: https://mailarchive.ietf.org/arch/msg/cose/YE8-De30lEk52p9bY9oxB74x0BE/ Thanks, Ivaylo
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
