> On Dec 13, 2020, at 2:10 PM, Ivaylo Petrov <[email protected]> wrote: > > > x5chain: This header parameter contains an ordered array of X.509 > certificates. The certificates are to be ordered starting with > the certificate containing the end-entity key followed by the > certificate which signed it and so on. There is no requirement > for the entire chain to be present in the element if there is > reason to believe that the relying party already has, or can > locate the missing certificates. This means that the relying > > Are the missing certificates required to be contiguous and contain the > root? That is, is it okay to leave a gap in the middle of the chain? > > [IP]: My reading of the text is that it would not make sense to have a gap in > the middle. My understanding is that each certificate in the chain after the > first one should sign the one that came before it.
I agree with Ivaylo on this. JWS is clear about this for the equivalent x5c parameter: https://tools.ietf.org/html/rfc7515#section-4.1.6 > > [still x5chain] > This header parameter allows for a single X.509 certificate or a > chain of X.509 certificates to be carried in the message. > > It's slightly surprising that the "chain" structure allows for a single > certificate not in an array container; it might be intuitively more > simple to just always use the array encoding for a chain, even a > one-element chain. But I'm sure there's some reason to allow it, too, > just not one that I thought of right away. > > [IP]: I can only see this as saving us 1 byte, but probably there are other > reasons as well. Seems like it would be less code if it was always an array and more inline with JWS. > [IP]: I like this wording and I added it as you suggested it. > > x5u: This header parameter provides the ability to identify an X.509 > [...] > As this header parameter implies a trust relationship, the > attribute MUST be in the protected attribute bucket. > > In light of the secdir reviewer's comments, perhaps "a trust > relationship between the party generating the x5u parameter and the > party hosting the referred-to resource" would help? > > [IP]: Done. Not sure where everyone’s thinking is about replicating section 6 from JWS <https://tools.ietf.org/html/rfc7515#section-6>. As you know I’ve mentioned this before and I think it is necessary. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
