Hi Ivaylo, Thank you very much for taking on this document after the dreadful news.
Your proposed sentence is an improvement, but I'm not sure how it combines with the earlier sentence "It is not necessarily expected that constrained devices themselves will evaluate and process of X.509 certificates". Is "evaluate and process" a different action than "validating" it? Or is the suggestion here that the constrained device is given a certificate to authenticate itself that it does not bother to verify, but hosts that connect to it *would* validate the certificate? Martin On Sun, Oct 11, 2020, 09:29 Ivaylo Petrov <[email protected]> wrote: > 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
