Re: [Anima] representing ACP info in X.509 certs

[Toerless Eckert <[e-mail]>]

Dear Stephen,

Thank you very much for your thoughts, but i do not think we can move
the discussion ahead when it stops with non-technical opinion dropping
statements like "lets not play games" (you) or "i do not think this
is the right thing to do" (Ben/Russ).

Could you please explain your assertion with technical arguments ?

More inline

On Tue, Jun 23, 2020 at 07:52:25PM -0400, Stephen Kent wrote:
> Brian,
> > Common sense argues against putting something other than an e-mail address in the rfc822namem attribute.
> > 
> > I expect ADs to use common sense, as well as careful reading of prior RFCs, when making decisions.
> > Indeed, but that cuts both ways, since running code is our goal. No parser is in a position to say that [e-mail] isn't an email address.
> 
> If we were only AIs that would be a suitable reply ;-).

I can only guess what this mean. You don't like the look of it as a human ?

I for once have been confused a lot by solutions where some data only
have a well-defined binary representation for "AI" ? to handle but none
for humans. In result, those solutions all are IMHO hard to troubleshoot, because
every CLI/GUI software came up with its own representation. For information
which naturally represents the domain, name and role attributes of an
entity, there is IMHO no better human recognizable standardized
representation in a single string than using the local-part@domain format.

ACP nodes in the acp.example.com domain only have one name, which is
their registrar assigned IPv6 address, therefore

   [e-mail]

really is the most human readible representation of that identification i can
think of.

   [e-mail]

The rfcSELF is just a prefix to allow isolation of namespaces in the
local part. Think of [e-mail] vs. [e-mail]

Likewise the +area51.research is just like a department name,
[e-mail]

A lot more legible than what poor network operators would normally see IMHO.

> But, we're not- we all know that the proposed IDs are NOT rfc822 addresses,
> so let's not play games.

This is not meant to be playing games. These are syntactically perfect rfc822Names/
email-addresses and semantically they can be perfect electronic mail boxes.
Remember that as the draft explains also in section 6.1.2, there is good amount
of prior examples where local-part@domain is used as just identifiers without
using any email boxes in the process. For example inter-domain access authentication,
eduroam or the like.

[ Then again, IMHO IETF is also supposed to develop new technologies,
  so i am not even sure why i always end up having to argue that solutions are
  better because they don't do something fundamentally new.]

> The simple answer is that when, in the past, developers have chosen to abuse
> the semantics of subject name fields in certs, the result shave been VERY
> long lasting, and embarrassing. Long ago, Netscape chose to shove a DNS name
> into the DN common name filed because it was an easy fix for their problem.
> As a result, we still have browsers and CAs that misuse that field. At least
> that egregious behavior was not the result of an IETF WG. Let's not screw
> this up in the name of expediency!

I have also not seen a reply from you to Michael Richardsons question about
that statement. I am not aware of the history, so i can not comment, but
i am curious about your reply.

Nevertheless, i do not think your example has any relevance here, because
we are not choosing a potentially wrong encoding for an existing 
piece of information, but we are arguing that our strgins are are perrfectly
syntactic and semantic correct electronic email addresses and therefore
deserve to use the standard encoding for electronic email addresses.

Cheers
    Toerless
> 
> Steve
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[e-mail]