Well, i definitely want to strick to string because otherwise i would
still have to write a standard human consumption representation, i
had enough problem with real world code across different systems
representing the same infor differently to the poor troubleshooter.
Application layer code is mostly strings too, and if one wants to map a name
from otherName <string> into e.g.: URN (urn:ietf:params:acp:<string>), then
there
would just be a 1:1 same <string> on both sides. And just that consideration
may be good enough right now not to have to bother with URN now in
this doc but define this later when needed - if nodoby feels there is sufficient
interop benefit to go to URI GeneralName instead of otherName (but me).
Cheers
Toerless
On Tue, Jun 30, 2020 at 09:34:11PM -0400, Michael Richardson wrote:
>
> Eliot Lear <[email protected]> wrote:
> > I think either a URI or otherName are pretty much functionally
> > equivalent. I might go with URI for one particular reason, which is
> > that the tooling ??? in particular OpenSSL ??? will handle it better.
>
> Maybe the command line stuff, but for the API, it's an identical amount of
> effort. (I have running code).
>
> I don't think an ASN.1 encoded otherName will be better for IoT (or BFRS)
> because it force the ACP application developers to learn something about
> ASN.1, and history says they will get it wrong. (Because, as Nico says, lack
> of access to ASN1 code generators).
>
> I would prefer CBOR encoding, if there is consensus that it should not be a
> string.
> This also anticipates more modern certificate-like artifacts (CoID).
>
> --
> Michael Richardson <[email protected]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
