Esko Dijk <[email protected]> wrote: > Thanks for reviewing!
>> Your PR goes from x5bag -> x5chain in many places, and I'm not sure I
>> understand why. A few places still say x5bag: I'm not sure which to
pick.
> It's basically changed to use x5chain to carry a certificate chain in
> order. Just trying to use the container as intended: x5chain is for
> chains (ordered), x5bag for "anything else" (including unordered
> chains).
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,
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.
>> Should all instances of x5bag go away?
> 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 :-)
>> I also wondered if there is any value in the self-signed RPK mechanism.
>> The Registrar can't really trust anything in the unprotected header, but
I
>> guess if it hasn't got the RPK via some other way, then at minimum this
lets
>> it verify the signature. The voucher arrived via HTTPS anyway.
>> So I do not object to including this instruction.
> The text was written with "live" (nonced) voucher creation in
> mind. There's a TLS protected session between Registrar and MASA, so
> the certificate / chain in the unprotected COSE "x5chain" container is
> protected by TLS (integrity).
okay.
> 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.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
