Re: [COSE] Martin Duke's No Objection on draft-ietf-cose-x509-07: (with COMMENT)

[Ivaylo Petrov <[e-mail]>]

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 <[e-mail]>
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