Hi, if David von Oheimb is correct that we've gotten use this Type=SpecificValue for the CSRATTRS wrong, then this certainly affects RFC8994, which requires that the pledge enroll with a specific otherName, allocated by the Registrar.
I don't think that we ever got reliably to /san when interoperating Registrars
in
2018's round of BRSKI testing. (Remember all those base64 issues...)
I expect to attempt this again between Registrar's again this month.
So, at least, we'll know if RFC8994/RFC8995 implementors got it consistent.
(Whether RIGHT or WRONG).
One answer is to just axe /csrattrs, and assume that the RA/CA will sort
things out. Eliot has proposed to do away with the ASN.1 in /CSRATTRS, and
do JSON and/or CBOR here instead. It certainly would be trivial to do,
and draft-ietf-cbor-tags-oid-08 could help here.
It's a bit of a toss-up of which bit of code you want to extend.
LAMPS chairs: can we have ten minutes for this discussion on the Thursday
Session III meeting at IETF111?
The Monday Session II is conflicted with ANIMA.
I'm gonna voluntold Eliot to lead this discussion :-)
--
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
