On Fri, Jan 29, 2021 at 03:27:27PM +0000, Göran Selander wrote: > Chairs and AD, > > As was raised in the latest in the latest COSE virtual interim, there > is at least one Github issue related to x5u that is not resolved > according to some people in the WG: > > https://github.com/cose-wg/X509/issues/31 > > I also agree with the issue that it is not clear what the trust > relationship is and why integrity protection is needed when fetching > the certificate in this case, which is not the case for the other COSE > header parameters x5t, x5bag, x5chain defined in this draft. For these > header parameters it is assumed that the certificate is verified, and > that suffices to determines if it is trusted. If trust relations are > relevant here, it seems also missing in this description the trust > relationship between the party hosting the referred-to resource and > party requesting the certificate.
To me there seems to be multiple problems: - As certificate used can affect interpretation, not just validity (especially so for signatures), the sender needs to bind the certificate used. This impiles x5t, x5bag and x5chain need to go into protected bucket. - HTTPS is transport encryption, so HTTPS URL do not bind fetched resource. So x5u needs to be paired with x5t, but could itself be in unprotected bucket. - The text seems to suggest that specially configured HTTPS server could assert COSE trust anchors. I do not think it is appropriate to use transport encryption for such purpose. - I think in X.509, it is possible for issuing certificate to affect interpretation of its subordinates. But I hope that very few pieces of software implement this insanity. In presence of such influence, x5t would not be sufficient. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
