> My belief is that anything you can do with x5chain you can do with x5bag. > The receiver will still need to pessimistic about the ordering, and in some > cases,
Right, I think so too. x5bag is already prepared for unordered cases. We could just use "x5bag" as the default carrier? > I think a clear ordering might not exist. I'm thinking about RFC4210 Section > 4.4, newWithOld certification authority chaining. I'd have to think about > all four cases to be sure. Such cases are relevant for EST (renewal cases). In BRSKI, during the "voucher stage", you would not typically see that - IDevID is considered immutable and forever-valid. Same goes for the builtin trusted MASA CA in the Pledge. But there could be other reasons for having unordered certs? Maybe a case where a MASA CA got updated, and Pledge products exist that have the old CA or the new CA. The MASA may not know whether a Registrar has the old or new CA in trust store, so it sends a complete set Old/New/NewWithOld to ensure the Registrar will be able to validate both "old" and "new" Pledges. > > Not all: we still use x5bag in some "SHOULD NOT contain" > > requirements. There it's helpful to mention both x5chain and x5bag, > > since 1) we've previously used x5bag ourselves and 2) otherwise there's > > an easy escape route from the requirement by changing x5chain to > > x5bag. > >I'm for having one way only :-) Given that COSE / RFC 9360 defines x5bag and x5chain together as two closely related features, and if we'd like to see only one variant is used in cBRSKI context (to avoid needless variation), then we can still say "SHOULD NOT use in the PVR" for both the variants. And say the Registrar "MUST remove in Voucher" for both variants. Is that what you meant? Another approach is only to mention one variant e.g. "x5bag" for these special considerations which keeps our text simpler. But it raises the obvious question of "what if I just use x5chain instead?". > > In the case that Vouchers are distributed non-live, they could go via > > unsecured data channels such as email or USB drives. > > We should maybe look at this case in more detail: in some specific > > cases, the Registrar can validate that the unprotected "x5chain" > > container hasn't been tampered with: > > It's the ZSTP case, and we've mostly ignored it at Someone Else's Problem. ZSTP ... <desperately looking up acronyms> ? I think the question was specifically for Voucher signed by RPK, which has no associated cert chain. Then it's only a single self-signed root CA cert that is included (per the new text) with the RPK as the public key. That should actually work for validation as I said in my previous email in point 1: the RPK is used to validate the self-signing first, and then to validate that the RPK also signed the Voucher. In case a cert chain is included in x5bag/x5chain, it would be by definition not an RPK but a "regular" Registrar EE cert that needs to chain to a trust root (CA) that the Registrar has installed. Esko -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
