rfc8366 did not define voucher-request, rfc8995 did. rfc8995
section 5.5 makes idevid-issuer mandatory in the voucher-request.
I think and said that it's mandatory in the voucher-request because
pledge/registrar can not know whether the voucher would otherwise
be unambiguous to the MASA.
So, let's first understand/agree on why rfc8995 makes idevid-issuer
mandatory in voucher-request. Especially if it's not what i wrote.
Then my next question is whether we can imagine any protocol other
than rfc8995 where idevid-issuer would not need to be mandatory,
and how that would work.
If we feel idevid-issuer would always need to be mandatory in
voucher-request, then i wonder how we would even express that
in rfc8366bis given how it's just imported from voucher into
voucher-request.
And if it was optional, then i also wonder how we would be able
to express the voucher-request specific guidance for idevid-issuer
in the definition of voucher-request given how its importet and
seemingly can not have a "description" field purely within voucher-request.
So, instead of bitching about X.400/X.500 and WebPKI vs private PKI,
i'd rather stick to the theme of this WG, which is to moan about
YANG when using it as we tried to (data artifact).
Cheers
Toerless
P.S.: Mahesh and Rob seemingly would like to see closure to the
errata, maybe they'll hold rfc8366bis hostage until we do, which
does make me ask the question how we can more quickly put a useful
end to the Errata other than what i proposed... All alternatives
seem to just require to redo the same Errata work over again..
On Thu, Jan 15, 2026 at 12:30:08PM -0500, Michael Richardson wrote:
>
> {I'm don't think the extensive CC is useful or productive}
Why not ? And what's 'extensive' in it ? What do you feel is superflous ?
> I think that the question we need to answer today, is whether the lack of
> perceived clarity is a problem that **RFC8366bis** should fix.
I think Mahesh and Rob would also want to bring closure to the Errata.
> We can change/update/extend the YANG description, and/or add text to another
> part of 8366bis explaining when idevid-issuer is needed.
> (It's not a BRSKI-only situation, I think. I think that the same
> considerations apply to SZTP...)
>
> Basically, this does come down to that SubjectDNs are not absolute, they
> depend upon the trust anchor.
>
> In 1980s X.400/X.500's fantasy, there was only going to be one global trust
> anchor, and strong Path Constraints would keep subordinate CAs in line.
> (does that sounds like an Admiral Tarkin line from _A New Hope_...?)
Before having fun derailing this discuss down those rants:
Why do we even need to bother about the quirks of private PKI:
To me, the question is whether idevid-issuer can be left out in
any voucher-request. Remember that rfc8366 didn't have voucher-request,
rfc8995 introduced that.
Funnily enough, the architecture of WebPKI is continuing to make a reality
out of that vision.
Given how the IETF is flooded with WebPKI geeks that often never worked
with private PKI with multiple uncoordinated trust anchors, it certainly
makes sense to provide 'superflous extensive explanations' ;-))
Hasn't Web PKI make a reality out of that ISO vision ?
Re
Folks that work with private PKI like us would also easily argue
that there is 'no need for extensive explanations'. Yet we know how
all tose
The core nature of private PKI is also something where
>
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
