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

From: Stephen Kent <[email-masked]>
Date: Sat, 20 Jun 2020 20:03:31 -0400

Folks,

My perspective matches what Russ & Ben have suggested, i.e., use of 
rfc822Name is inappropriate for this context. RFC 5280 is very clear 
about the intended use of the rfc822Name field in a cert and the 
proposed use in the anima context is inconsistent with 5280 text. A 
reasonable, appropriate way forward is to define a new otherName type 
for the anima context.

Steve

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 20 Jun 2020 18:25:37 -0700

This matches my understanding as well.

One thing that's not clear to me: is the expectation that you will be using
a public CA or that you will be using an enterprise-level one?

-Ekr

On Sat, Jun 20, 2020 at 5:03 PM Stephen Kent <stkent=
[email-masked]> wrote:

> about the intended use of the rfc822Name field in a cert and the proposed
> use in the anima context is inconsistent with 5280 text. A reasonable,
> appropriate way forward is to define a new otherName type for the anima
> context.
>
> Steve
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 21 Jun 2020 12:09:10 -0400

Eric Rescorla <[email-masked]> wrote:
    > One thing that's not clear to me: is the expectation that you will be
    > using a public CA or that you will be using an enterprise-level one?

There are different many use cases, and it is precisely because we can't be
prescriptive about the operation of the CA involved that the WG compromised
on a solution that we know can be deployed today.
I wasn't happy with the result, but I realized that I could live with the
compromise result.  The WG did consider all the points that you have raised.

1) a private-CA internal to the ACP Registar.

2) an enterprise private-CA external to the ACP Registrar, which is embedded
   in another system, such as ActiveDirectory

3) when we started this work, it was possible to have (a) and (b) with
   anchors toward public CAs

4) an enterprise private-CA external to the ACP Registrar, which is
   operated by a third party, which might use ACME or something else to enroll

5) a small (or growing) enterprise entity that uses ACME to a public CA.
   The is no "group" policy to deploy a private CA, and there is a strong
   desire that the devices that are enrolled do not train users to think
   security exceptions are "normal".
   Obviously, the DN presented to a browser is not a rfc822Name,
   but would have to be an dnsName.  The ACP rfc822Name
   may not be the only SAN in the certificate, but it is one that
   draft-ietf-acme-email-smime-08 allow the Registrar to validate.

6) virtual corporation, where most of the systems are "hosted" systems
   in "the" cloud.  Some of these scenarios are described by
   https://datatracker.ietf.org/doc/draft-friel-anima-brski-cloud/

7) construction-site scenarios, where EE LDevID will "be left behind"
   for the eventual home owner, who could rekey into 1-6.
   see https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Jun 2020 10:35:25 -0700

> compromise result.  The WG did consider all the points that you have
raised.

Well, strictly speaking, I believe it was others who raised the points;
however, I do concur with them. In any cases, as Ben notes, this decision
cannot be made by this WG alone.

>    in another system, such as ActiveDirectory

I am not particularly expert on private CAs, though I see that
Sean made some notes on what could be done with that software.

>    anchors toward public CAs
...

>    draft-ietf-acme-email-smime-08 allow the Registrar to validate.

I'm assuming that by "public CA" we are talking about a CA which
issues certificates which are acceptable to browsers or other generic
clients. On that topic, I would make a few points:

1. It is not impossible to get CAs to issue certificates with custom
extensions. For instance, DigiCert issues certificates with the
Delegated Credentials extension:

   https://engineering.fb.com/security/delegated-credentials/

It's of course possible that otherName would be different.

2. I believe the Mozilla Root Store Policy [0] would require a CA to
revoke certificates used as described in this specification. See
Section 6.2 (S/MIME Certificates) [1]:

   For any certificate in a hierarchy capable of being used for
   S/MIME, CAs MUST revoke certificates upon the occurrence of any of
   the following events:

   ...

   3. the CA obtains reasonable evidence that the certificate has been
   used for a purpose outside of that indicated in the certificate or
   in the CA's subscriber agreement;

I imagine that other root programs have similar restrictions.
Of course this wouldn't preclude a CA that wasn't subject to these
restrictions issuing ACP certificates.

-Ekr

[0]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
[1] There are a number of other clauses which I believe would also apply,
but I believe this is the most on-point.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 23 Jun 2020 03:31:45 +0000

Being completely pedantic about the RFC5280 text, nowhere in the text does it say that rfc822name cannot be used for anything but email address. It does state multiple times that an email address must be represented as an rfc822name, but places no explicit restrictions on what an rfc822name may represent. The text as is does not explicitly preclude use of rfc822name for ACP. This may be the widespread understanding of what RFC5280 means, but its not strictly what it says…

From: Anima <[email-masked]> On Behalf Of Eric Rescorla
Sent: 21 June 2020 09:26
To: Stephen Kent <stkent=[email-masked]>
Cc: Anima WG <[email-masked]>
Subject: Re: [Anima] representing ACP info in X.509 certs

One thing that's not clear to me: is the expectation that you will be using a public CA or that you will be using an enterprise-level one?

-Ekr

On Sat, Jun 20, 2020 at 5:03 PM Stephen Kent <stkent=[email-masked]<mailto:40verizon.net@dmarc..ietf.org>> wrote:

Folks,

My perspective matches what Russ & Ben have suggested, i.e., use of rfc822Name is inappropriate for this context. RFC 5280 is very clear about the intended use of the rfc822Name field in a cert and the proposed use in the anima context is inconsistent with 5280 text. A reasonable, appropriate way forward is to define a new otherName type for the anima context.

Steve
_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jun 2020 11:46:16 -0400

Owen,
>
> Being completely pedantic about the RFC5280 text, nowhere in the text 
> does it say that rfc822name cannot be used for anything but email 
> address. It does state multiple times that an email address must be 
> represented as an rfc822name, but places no explicit restrictions on 
> what an rfc822name may represent. The text as is does not explicitly 
> preclude use of rfc822name for ACP. This may be the widespread 
> understanding of what RFC5280 means, but its not strictly what it says…
>
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.

Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Jun 2020 08:34:38 +1200

Regards
   Brian Carpenter

On 24-Jun-20 03:46, Stephen Kent wrote:
> 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 [email-masked] isn't an email address.

   Brian

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Jun 2020 19:52:25 -0400

Brian,
> Indeed, but that cuts both ways, since running code is our goal. No parser is in a position to say that [email-masked] isn't an email address.

If we were only AIs that would be a suitable reply ;-).

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

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!

Steve

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Jun 2020 20:55:40 -0400

Stephen Kent <stkent=[email-masked]> wrote:
    > 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!

Yes, I remember that.
Why do you think Netscape did that?
What should they have done instead?

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Jun 2020 09:04:59 +0200

Hi there,

> On 24 Jun 2020, at 02:55, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

Going further, sometimes expedients are appropriate.

With the benefit of hindsight of nearly 30 years of experience, there’s a lot that Netscape did in its first years that we wouldn’t do today, but had they not done those things, field delivery could have been delayed by years, probably the worst example being the User-Agent header.  We can say, “they never should have done that”, but it was what people deemed necessary and expedient for a number of reasons, not least of which was product differentiation and market maturity.

Here we have a situation where the public CA offerings have been made quite brittle. The ability to add either an otherName or a URI requires CAs to modify their code and create alternative roots.    We all know that won’t happen, and so that leads to whether an expedient is appropriate.  Worse, as I have demonstrated, submitting otherName to public CAs produces garbage in certs (very bad, but there it is).  They not only aren’t ready, but they may have potential exploits lingering.

Is an expedient appropriate?

With ACP it’s clear they are overloading semantics of an rfc822name, and from an application standpoint we don’t like that because it is possible that different subsystems may have different uncoordinated allocation methods.  That is- someone may be able to nab an email address via the mail subsystem a la [email-masked] <mailto:[email-masked]>, get a cert for that address, and masquerade as an AN or an AN could start sending email as a user that has such an address.  Let’s agree that the latter is so minimal a risk as to not warrant further discussion.  It’s only the former that’s really of concern.  That can be mitigated through operational guidance, a’la “don’t allow email addresses in your domain that begin with rfcSELF+”.

It’s not perfect.  That’s the nature of an expedient.  But it’s probably Good Enough for now.  For the eventuality that another name could be used over time, it’s probably worth getting an OID and using otherName where possible, but we shouldn’t hold this work up over a highly theoretical attack.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Jun 2020 11:39:33 +0200

Thanks, Eliot,

inline

On Wed, Jun 24, 2020 at 09:04:59AM +0200, Eliot Lear wrote:
> With ACP it???s clear they are overloading semantics of an rfc822name,

What is your definition of "overloading" ?

There are all type of entities addressed with rfc822name, not only
people, but also functions and devices have been given rfc822names as well forever.
Ok, so the name part is somewhat strange because it's numeric.
How about companies giving users email addresses that are serial numbers.
Quite ccommon actuall i think. [email-masked] - also roles can be found in
rfc822names. We're just doing what everybody and their dog has done
with rfc822 names forever.

> and from an application standpoint we don???t like that because it is possible that different subsystems may have different uncoordinated allocation methods.

I don't think this is true

>  That is- someone may be able to nab an email address via the mail subsystem a la [email-masked] <mailto:[email-masked]>,

The example explicitly used acp.example.com instead of example.com
to ensure that allocation of email addresses in such a specific
subdomain was not simply possible for arbitrary users who might
allocate email addrs under example.com. Its common practivce
in enterprises to have all type of subdomains for specific
functions not accessible to the standard mail system setup.
Arguing you can get an email address is like arguing you can
fake a domain name in such a controlled environment. And see 
the following: it wouldn't even be good enough.

> get a cert for that address

Not from the necessary TA.

> , and masquerade as an AN or an AN could start sending email as a user that has such an address.

No.

See section 6.1.4

|  Certificates for an ACP MUST only be given to nodes that are allowed
|  to be members of that ACP.  Because the signing CA relies on an ACP
|  Registrar, the CA MUST only sign certificates with ACP domain
|  information through trusted ACP Registrars.  Any existing CA, unaware
|  of the new ACP domain information field, can be used as long as it
|  only allows signing requests from trusted ACP Registrars and from
|  nodes or registrars trusted not to include ACP domain information in
|  their certificates.

|  These requirements can be achieved by using TA private to the owner
|  of the ACP domain or potentially through appropriate contractual
|  agreements between the involved parties.  Public CA without such
|  obligations and guarantees can not be used as TA for ACP domains, but
|  they can be used to obtain certificates for TAs of ACP domain.

Aka: The ACP trust model is built on controlled access TA and 
specific functionality registrar, it does not matter at all which
field the information is encoded into for the trust model described.

>  Let???s agree that the latter is so minimal a risk as to not warrant further discussion.

Lets agree this would only happen by explicit violation of
mandatory document requirements by a real misguided operator. And
under those circumstances most RFCs would not be safe.

>  It???s only the former that???s really of concern.  That can be mitigated through operational guidance, a???la ???don???t allow email addresses in your domain that begin with rfcSELF+???.

Actually right now my personal recommendation would be to allocate that
email address (prefix) rfcSELF{+...}@.. to the ACP admin to see if there was ever
some unintended side effect such as email to that address
that was generated by other software.

Btw: ANIMA and ACME folks had a side meeting last year (i think you
where there ?!), and of course one of the ideas is to be able
to use ACME mail signed certs in the future, but this is outside
the scope of the document. But the recommendation
in the doc to use an ACP domain name part that you own already
prepares for that, so i think it should be fairly easy to use
in the future ACME web PKI as TA just from the perspective of
using the ACP rfc822name as the validation email mechanism. There
may be other ACME issues to resolve though.

> It???s not perfect.

Thats how i started to think of initially as well coming from
just the problem of how to overcome ossification of the ecosystem
we have to deal with. But in the meantime i think the format
of rfc822name is near perfect for both human consumption as well
as for managing it - has domain-name to tie into something you
can have authoritatively. 

>  That???s the nature of an expedient.  But it???s probably Good Enough for now.  For the eventuality that another name could be used over time, it???s probably worth getting an OID and using otherName where possible, but we shouldn???t hold this work up over a highly theoretical attack.

I think the reason for solutions that like to reuse the
rfc822name format of local@domain but choose new encoding
points is so that they can reuse existing local@domain
user identifiers but indicate a specific app. Much
like a uri scheme of newapp:local@domain

In the case of ACP this is not necessary, because we
simply distinguish on the local part and/or the domain
name. No need to support overloading of the same rfc822names
for different uses. That is something more relevant to
humans who like to have a single local@domain ID for 
themselves across all apps. ACP IDs are more functional IDs.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Jun 2020 12:40:48 +0200

> On 24 Jun 2020, at 11:39, Toerless Eckert <[email-masked]> wrote:
> 
> Thanks, Eliot,
> 
> inline
> 

If the ACP subsystem allocates a name and the user management system allocates a name, then you have the potential of a conflict.  Again, the odds of an actual conflict are very low.

> the following: it wouldn't even be good enough.

You can make an operational recommendation of course.  However, some enterprises simply do not do subdomains (I email from one such enterprise now).

> |  nodes or registrars trusted not to include ACP domain information in

Ok, but...

> field the information is encoded into for the trust model described.

If the TA is itself signed by a public CA, then the CA can sign other names or for that matter issue other signing certs , and (at least by normal use of PKI) the name will validate without the TA ever having been used.  Assuming that’s not what you mean, how does the client know which TA is authorized?

> that was generated by other software.

I like that idea.

> like a uri scheme of newapp:local@domain

This requires a broader discussion that need not hold up this draft.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Jun 2020 22:06:07 +0200

Thanks, Eliott, inline

Btw: Just seeing that the folks holding the DISCUSS are not
explicitly included in this thread... not sure if they 
follow the anima WG mailing list overall... Cc them ?

> If the ACP subsystem allocates a name and the user management system allocates a name, then you have the potential of a conflict.  Again, the odds of an actual conflict are very low.

Whether or not there is ACP, we are talking about about an app
that has access to certificates on routers that could have rfc822name
and the app would send emails to those rfc822name addresses
and something good would happen.

I am quite sure that such an app does not exist, but it could
be nice, so lets call it the unicorn app. The ACP rfc822name
structure certainly allows for unicorns.

If you want to deploy ACP and you don't care about unicorns,
you ignore the issue. The conflict you are talking about would
only hurt the unicorn but not the ACP.

When you do care for unicorns you have several options:

a) You can make sure that the local part name space is well managed
so local part names for ACP can not be incorrectly assigned
to other purposes. Likely works by default because common
solutions that let users assign local names or aliases have
length limits < ~ 30 characters and ACP local part is 40 + X
(X being extensions). Upper limit in rfc822name is btw 64
for local name part.

b) You use a different name or subdomain (see) to separate
name spaces between users and the names you use inside
network operations / ACP. Most common solution IMHO.

c) You train the unicorn to forward the names based on where
they are found to another domain. typical setup in email
ssytem when there are logical names but distributed MTA.

> You can make an operational recommendation of course.  However, some enterprises simply do not do subdomains (I email from one such enterprise now).

Different (Sub)domains are the standard tool to separate
local-part namespaces in rfc822. It is widely used in
enterprises

Do not confuse what you as the user see with whats under
the hood in RFC822. As soon as you have multi-vendor
distributed MT setups you will use different subdomains
under the hood with forwarding and name aliasing/hiding.
The vendor you work for even sells comms products with MTA
in them that would do that last i checked (couple years back).
I am sure if you could look at the whole domain space of
your employer, you would find a lot of subdomains, including
for other MTAs.

But then again, whatever is visible to the outside, both
domains and local name parts is subject to corporate comms
policies, so indeed it is likely that subdomains would only
be available to what that department likes. Many
network operations orgs in SP/enterprise therefore just
buy their own domain name that has nothing to do wih
their enterprises "brand" domain name and use that other
domain to freely asign names for routers, network exquipment
and network ops related MTA, web servers etc. And then make
sure none of these domain names are on public accessible
DNS servers/zones. 

So, if example.com was a typical brand-marketing lead enterprise,
the network ops teams would ask to get acp.example.com and
even though they may actually run the example.com DNS and MTAs,
they wouldn't be the one permitted to decide whats on it,
so after four months of discussion, the network ops team
would go buy example.org and use acp.example.org.

> If the TA is itself signed by a public CA, then the CA can sign other names or for that matter issue other signing certs , and (at least by normal use of PKI) the name will validate without the TA ever having been used.  Assuming that???s not what you mean, how does the client know which TA is authorized?

ACP nodes are initialized before ACP can run by a registrar
with a cert and the appropriate TA.  Cert and TA are renewed
via EST automatically before they expire. So TA are fully
controlled by the registrar(s).

The public CA would never be a feasible TA. Only the private root cert
would be an appropriate TA. Whether that private root cert is
self-signed or signed by a public CA is irrelevant, that would
not change the result of an ACP cert chain validation: The
cert chain validation MUST terminate in a TA. The attackers
cert you mention would only be signed by the public CA, which is
not a TA for the ACP.

I don't think there is any benefit of letting private root CA certs
as required by ACP to be signed by public CA today. Thats also
not done with any of the private root CA certs i know from
enterprises, so nothing new here with ACP.

With ACME mail we would get new options, but one has to see how
more beneficial they are from just having an enterprise run its
own private CA solution. You can easily buy private CA solutions
as a cloud service from the usual suspectsa. I think the ACME
stuff is primarily when you do want to use the certs for
external authentication, which ACP wouldn't need unless we
go into maybe future ACP for federations.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jun 2020 14:11:08 -0700

> follow the anima WG mailing list overall... Cc them ?

I should clarify that I am not holding a DISCUSS as I am no longer on the
IESG. That's what the parentheses around my position in datatracker mean,
which is to say that I dropped off the IESG while my DISCUSS was pending.
To the best of my knowledge it doesn't have any special status and is just
kept around as a historical reference.

I certainly have opinions here, but I'm weighing in as a community member,
as are Stephen, Russ, and Sean.

-Ekr

> > If the ACP subsystem allocates a name and the user management system
> allocates a name, then you have the potential of a conflict.  Again, the
> odds of an actual conflict are very low.
>
> > You can make an operational recommendation of course.  However, some
> enterprises simply do not do subdomains (I email from one such enterprise
> now).
>
> > If the TA is itself signed by a public CA, then the CA can sign other
> names or for that matter issue other signing certs , and (at least by
> normal use of PKI) the name will validate without the TA ever having been
> used.  Assuming that???s not what you mean, how does the client know which
> TA is authorized?
>
> > >> That???s the nature of an expedient.  But it???s probably Good Enough
> for now.  For the eventuality that another name could be used over time,
> it???s probably worth getting an OID and using otherName where possible,
> but we shouldn???t hold this work up over a highly theoretical attack.
> > >

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 27 Jun 2020 16:19:11 +0200

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

> 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

   [email-masked]

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

   [email-masked]

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

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

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.]

> 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

-- 
---
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Sat, 27 Jun 2020 12:35:35 -0400

Toerless,
> Could you please explain your assertion with technical arguments ?

The ID goes to great lengths to justify the use of the rfc822Name field 
for this context, rather than defining a new data type.  If this was the 
obvious "right" thing to do, there would not need to be so much text 
justifying the choice ("The lady doth protest too much, methinks").

I am not an AD;  I don't have a vote on this. If PKIX were still an 
active WG, and if someone came to me and asked about the choice of 
identifier in the ACP context, I would say that it was a questionable 
choice, given 25+ years of experience with PKI standards and technologies.

As I noted in a prior message, when Netscape elected to shove a DNS name 
into the common name field, it was a questionable choice, and we have 
had to live with the result for 20+ years. Elliot Lear's messages  
suggest that this choice was motivated , at least in part, by 
expediency, but he believes that sometimes expediency is an OK 
justification in these matters. Personally, I don't, but, ...

Steve

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 28 Jun 2020 01:10:26 +0200

On Sat, Jun 27, 2020 at 12:35:35PM -0400, Stephen Kent wrote:
> The ID goes to great lengths to justify the use of the rfc822Name field for
> this context, rather than defining a new data type.  If this was the obvious
> "right" thing to do, there would not need to be so much text justifying the
> choice ("The lady doth protest too much, methinks").

Seriously ? Because some people people do not like it and the text
goes to great length to technically explain the choices, your
conclusion is that it must be wrong ? Do you call that a technical argument ?

> I am not an AD;  I don't have a vote on this.

The IETF does not vote. We supposedly have rough consensus. I thought
that means that it needs to have a sufficient community to be interested
work (we hae that, ANIMA WG), and it needs to pass technical challenges.
It should IMHO NOT mean that people who do not have a technical arrgument
 should be able to just succeed by creating a flash mob rejecting the
choice and arguing "The lady doth protest too much".

Aka: Yes, you did miss the timeline (just about 5 years ongoing) to
argue your preference how to encode in the WG before last call. You
and everybody ense in this discussion should IMHO stick to providing 
technical challenges why the ANIMA WG choice can technically not appropriate
or suggest better technical choices. But such proposed better technical
choices can not simply ignore the requirements described by the
solution, and those include the long list that you like to refer to
in the negative without (i think) even having read them.
(section 6.1.2 numbered lists).

> If PKIX were still an active
> WG, and if someone came to me and asked about the choice of identifier in
> the ACP context, I would say that it was a questionable choice, given 25+
> years of experience with PKI standards and technologies.

How about ANY technical argument. If you hae experience, you would
be able to make a technical argument.

> into the common name field, it was a questionable choice, and we have had to
> live with the result for 20+ years.

If your example was actually applicable to this case, you wuld be
able to describe the problem without that example. I replied to
your prior email stating that i think that eample is non-applicable
to this case.

> Elliot Lear's messages  suggest that this choice was motivated,
> at least in part, by expediency, but he believes
> that sometimes expediency is an OK justification in these matters.
> Personally, I don't, but, ...

What experience do you have with backbone/WAN router/switches and NOC
software ecosystems ?  If you had any idea how fragmented/duplicated/
and ossified the target deployment environment is, you too would look
for appropriate solutions that avoid unnecessary forklift
upgrade requirements. Thats exactly what new attribute types introduce
to achieve the same degree of ecosystem support as using existing
cert attributes.

Of course, this means that the solution to use an existing attribute
must accordingly match the requirements for such use. So now this
document has a long list of explanations why this is the case, and
the only rejections we are getting are opinions, but no technical
arguments.

-- 
---
[email-masked]