Esko Dijk <[email protected]> wrote: > It defines usage of idevid-issuer in the Registrar Voucher Request > (RVR). But yes it doesn't speak about it for use in the Voucher. > In certain cases the MASA needs to receive this information from the > Registrar; e.g. in the scenarios a) b) c) that you sketched, > to select the right signing authority out of multiple.
Right, it is there.
I was looking at the document when I wrote my email, and I thought that I
searched for it, and didn't find it. But there it is in section 5.5.
The Pledge doesn't really know if it has to include it, because it doesn't
know if a merger (or other action) has occured since it was shipped. I
think that the pledge can omit it whenever it has included it's IDevID
certificate.
The Registrar has no idea if it needs to include it.
I conclude that it has to always include it since it has no way of knowing.
My MASA uses the certificate as the key to find the pledge's database entry
so I haven't noticed it's absense.
The examples do not include it :-(
>> I think that we will say this (voucher-requests do not need
idevid-issuer) in
>> the constrained-voucher document. Since we extend the YANG, we can
refine
>> the constrained-voucher part.
> Ideally we update the YANG of voucher-request-constrained to document
> the usage of idevid-issuer in the RVR. (RFC 8995 should have done that,
> but alas.)
> "do not need idevid-issuer" is mostly true for the Voucher. I do see a
> particular corner case where idevid-issuer is needed in the Voucher to
> avoid identity confusion,
> I can write that down some other time.
Thank you.
My other idea is to obsolete it, on the assumption that private keys are
never repeated.
--
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] https://www.ietf.org/mailman/listinfo/anima
