Göran and Ilari: >> 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.
Since the certificate is signed, it can be bound by including an identifier from the certificate in the protected part message. The subject key identifier is one way to do this. That is, the whole certificate does not need to be in the protected bucket. Russ _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
