Subject: [Anima] rfc822Name "abuse" in Autonomic Control Plane document

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Jun 2020 20:20:33 -0400

Hi, I have had a few conversations with Toerless who is trying to deal with
the feedback on the ACP document.

An item that has come up is the use, or claimed abuse of the rfc822Name SAN.

We already had this debate.
Some time ago.  The WG decided.
Three or four years ago, I think.

I sure wish that we could use something else.
But, CAs and CA software make that very difficult.

Given that the era of publically anchored Enterprise CAs is dead, there are
only two ways an (Enterprise) ACP Registrar is going to occur.

1) by running a private CA.
   Sure anything is possible if you are writing your own code, but
   most will not be doing that. (I've supported otherName in my code for
   other purposes, and it's not that difficult, but it's not trivial either)
   My experience with COTS CA systems it that it's really hard to
   get them to do it.    Please prove me wrong.
   The most popular Enterprise CA software is the Microsoft CA.

2) by using ACME to speak to a hosted CA.  Maybe WebPKI, maybe not.
   Either way, getting otherName supported is even harder, because
   nobody else uses it.

If we can't depend upon otherName being filled in, then we have to look for
two things.  That means more code paths (two more) to test, more test
vectors, and what exactly does an end point do when both are present, BUT
THEY DO NOT MATCH?  So three more pages of text there.
Remember, that just rejecting the certificate means that we have to send out
a truck, which is what ACP aims to avoid, so that won't be popular.
And of course, there could also be bugs (maybe even CVEs) in the code that
tries to deal with the tie.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 16 Jun 2020 14:14:24 +1200

> Three or four years ago, I think.

Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS:

https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc

The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26

I believe it is incorrect IETF process to rediscuss this point yet again.

   Brian

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Jun 2020 19:44:12 -0700

Hi Brian, Michael,

> > Some time ago.  The WG decided.

With all due respect, this is not the sole decision of the ANIMA WG to
make.  If WGs had such authority then why bother with cross-area review?

> https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc

In this message, I say that "I still feel like this is not the best
architectural choice" and that I will provide a sketch of an alternative in
my (then-)forthcoming ballot position; that ballot position retains the
Discuss-level concern about rfc822Name usage along with the promised
alternative.

> The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26

I appreciate that the attempted justification is clearly written; however,
I do not find it compelling.  Russ did not, either, and I just heard back
from Sean Turner a few days ago to confirm that he supports Russ's
comments.  (There should be a few other editorial-ish comments that came
out of that review that are still pending.)

> I believe it is incorrect IETF process to rediscuss this point yet again.

(I'm not sure if the "yet again" refers to "after the WG decided" or "after
the (alleged) resolution of my first Discuss point".)

If you believe the technical answer is clear and that I am in error to
continue to hold my Discuss point for it, are there not also clear IETF
processes to follow?  E.g., asking for the "Single Discuss" ballot procedure
described at https://www.ietf.org/standards/process/iesg-ballots/?  I
believe I have mentioned this option to Toerless previously; my apologies
if that is not the case.  While I'm willing to continue discussing the
topic and pull in additional PKIX experts to weigh in, there is perhaps
some consideration to matters of expediency.

> >    get them to do it.    Please prove me wrong.

(Sadly, I have zero experience with COTS CA systems; I know too much about
openssl at this point and would presumably be writing my own, in this
position.)

> >    Either way, getting otherName supported is even harder, because

Is the concern the ACME protocol support or just getting the hosted CA to
cope with it?  The former seems like something that we could make happen in
the IETF, and the latter seems to have high overlap with point (1).

> > tries to deal with the tie.

To be honest, this argument feels like a stronger one to me than the bits
in the -24.  I'm still not willing to accept into the RFC Series a document
that violates the rules set down by the specification for the technology
it's making use of, but the refocus on the "running code" aspect is
appreciated.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jun 2020 16:08:35 -0400

Ben, this is getting very very tiresome.

PLEASE go read RFC7282.
"Rough consensus is achieved when all issues are addressed, but not necessarily accommodated"

Also:
   A diligent chair who's been carefully listening to the
   discussion might think, "I have heard person X make this objection,
   and I've heard responses from many other folks that really address
   the issue.  I think we have rough consensus.

I will note that *I* objected to rfc822Name. (And that I changed my mind.
I can live with it)

But, you have been effectively weidling a veto on quite a number of drafts, and
that is not in the spirit of rough consensus.  It's just not your job.

If it were your job, then we would not have WGs, Adopton calls, we would not
do WGLC reviews, nor WG charters, etc.   We'd just submit our documents to you.

But, this is not only your fault: had the rest of the IESG actually voted rather
than Abstained or No Comment, then we'd have actual rough consensus, and the
IESG seems to have abandonned that.

    > make.  If WGs had such authority then why bother with cross-area

https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/
says: Reviews

RTGDIR Last Call Review: Not Ready
IOTDIR Early Review (of -18): Ready
SECDIR Telechat Review (of -16): Has Issues
GENART Telechat Review (of -16): Ready with Nits
RTGDIR Telechat Review (of -13): Ready
SECDIR Early Review (of -13): Has Issues
GENART Last Call Review (of -13): Not Ready

(Unfortunate that many reviewers do not update their opinion when we act on
their advice.   So, for instance, the SECDIR review says in her text that it
is ready)

I guess you feel that it hasn't been cross-area reviewed unless you have
blessed it?  I think you should probably disband the SECDIR, because they are
clearly not helping you or anybody.  In fact, those reviews are just wasting
everyone's time.

So, our process is that the *WG* takes these views into account, and
then makes a decision.
That includes sponsoring AD reviews and IESG comments.
The WG took the objections to rfc822Name into account already.
You do not have the right to override the WG decision.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Jun 2020 18:37:20 +0200

Ok, so I just want to add that I have been able to populate otherName with garbage and have it get signed by a public CA.  My point is that at least some public CAs are loose.  If LE is important to this space, and if it’s really important, then this is not a solution.  Anyway, Here was the line that I used for my jabber server (it’s certainly not correct):

subjectAltName = DNS:www.ofcourseimright.com,DNS:upstairs.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:_xmpp-client._tcp.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;IA5:_xmpp-server._tcp.ofcourseimright.com,otherName:1.3.6.1.5.5.7.8.7;UTF8:ofcourseimright.com

And here’s what I got:

McNext> openssl x509 -noout -text -in jabber_ofcourseimright_com.crt 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            58:12:20:cd:47:fe:82:af:35:8d:75:50:75:05:a6:cb
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA
        Validity
            Not Before: Jun 18 00:00:00 2020 GMT
            Not After : Jul 18 23:59:59 2020 GMT
        Subject: CN=jabber.ofcourseimright.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9e:c8:c0:61:b6:5c:d1:fc:bf:2d:d2:13:6b:db:
                    97:09:45:e8:22:bf:89:24:7e:09:01:fe:91:37:85:
                    ee:25:77:54:92:68:05:07:d2:70:f5:6f:5c:fc:b4:
                    c6:7f:2d:e6:3e:11:68:4b:55:74:10:39:bc:1c:19:
                    3c:82:76:c1:76:ad:9b:6a:be:c3:be:35:dc:e5:5a:
                    48:95:2c:c9:9f:d7:68:c6:6f:83:b4:8d:c8:8a:0a:
                    b8:73:2e:10:c9:0e:a1:70:cb:a4:29:a0:b3:32:34:
                    72:69:9a:7d:20:35:9c:58:f1:a3:17:3f:fd:6f:22:
                    23:e5:58:24:65:56:38:51:6f:10:46:4b:77:fb:2d:
                    c9:5b:ca:db:8e:74:77:20:8b:b4:04:0a:63:75:03:
                    4c:be:19:9f:1f:9a:63:cd:9b:12:3e:b3:09:10:de:
                    d0:a1:d3:8b:bc:83:66:6a:4e:28:3c:5f:f7:ab:23:
                    a7:b6:da:46:59:21:eb:d7:ef:57:53:d8:72:be:55:
                    07:a5:95:c9:61:97:f7:39:c0:78:82:c0:1e:bd:53:
                    fc:ae:2c:6c:7a:c2:69:a0:c4:80:44:ac:b3:6b:f8:
                    01:fc:8f:ab:7e:8b:b8:24:0e:cd:7b:0e:74:94:77:
                    1c:4d:11:a2:d8:36:53:08:1a:d8:1b:fc:23:86:4c:
                    b3:f1
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:8D:8C:5E:C4:54:AD:8A:E1:77:E9:9B:F9:9B:05:E1:B8:01:8D:61:E1

            X509v3 Subject Key Identifier: 
                65:8C:F2:D4:46:7C:FB:D1:5E:62:BC:8C:70:B6:99:D0:95:4B:EB:98
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.6449.1.2.2.7
                  CPS: https://sectigo.com/CPS
                Policy: 2.23.140.1.2.1

            Authority Information Access: 
                CA Issuers - URI:http://crt.sectigo.com/SectigoRSADomainValidationSecureServerCA.crt
                OCSP - URI:http://ocsp.sectigo.com

            X509v3 Subject Alternative Name: 
                DNS:jabber.ofcourseimright.com, DNS:www.jabber.ofcourseimright.com
            1.3.6.1.4.1.11129.2.4.2: 
                ......v...\..}h.....#....W|W..j..a:.i......r.e.......G0E.!...f...R...r.S...w.E%.}.J.i.M..... )................!.0...L.e.fs.Z..w.....7~.b....a...{7.V..&[...K.ATn...r.e.:.....H0F.!....~...V.....5F.h.\C.....e.'57.{.!.. 8.I...8...U.Y........f._.6..bb
    Signature Algorithm: sha256WithRSAEncryption
         1c:0d:7b:38:be:c5:b5:58:8e:0e:d9:7d:c8:90:9d:ea:29:94:
         de:a7:a1:11:db:1e:b7:9c:f8:25:48:da:2d:87:2f:76:0b:f8:
         ba:2d:72:49:87:50:3e:e2:9b:2f:a4:ab:61:24:8c:6c:65:c1:
         91:16:c2:7e:50:27:50:93:a8:36:38:ad:66:c4:e4:66:ae:2f:
         21:40:8f:41:f7:53:51:61:80:59:a8:2a:56:9b:9b:e5:85:a4:
         8b:6e:31:0b:b8:ca:4d:82:af:2c:34:83:25:2b:fc:94:05:28:
         f6:04:f8:96:61:3c:21:9b:11:13:48:1d:c0:77:c0:df:d3:47:
         ff:6e:d3:6a:66:eb:16:40:d7:45:67:a0:25:1d:9f:fa:7f:85:
         20:34:08:70:b2:3b:d5:b4:15:77:9b:d5:c0:4e:08:99:ce:24:
         fb:6e:c3:4d:a9:fc:ff:25:d9:09:d0:cd:e1:8b:69:c1:bb:f0:
         40:0a:ad:1b:36:4f:ba:a0:aa:e9:f1:af:cd:73:5a:2a:0f:8a:
         0d:04:ca:52:85:10:eb:d9:fe:85:6c:a6:ae:a3:de:04:a7:9a:
         e0:8c:5d:40:b6:1f:f6:f2:b1:d9:dc:f2:f4:fd:a8:f5:b4:25:
         80:c0:ec:84:1f:bf:02:e6:3d:0c:ca:41:d5:61:d9:a3:a2:c8:
         a0:f2:46:3c

Eliot
> On 17 Jun 2020, at 04:44, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Brian, Michael,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Jun 2020 17:11:30 +1200

Hi Ben,

(Back on line after a couple of days spent moving apartments.)

> make.  If WGs had such authority then why bother with cross-area review?

Yes, but that was exactly the reason we had the discussion a year ago.

> Discuss-level concern about rfc822Name usage along with the promised
"Not the best choice" is not a DISCUSS criterion according to the IESG's own rules at https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc

It was exactly this sort of endless debate over "best choice" disagreements that caused the IESG to adopt the DISCUSS criteria rules in the first place.

If you are saying that one of the criteria in https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc applies, that's a different matter, of course. But really, no AD should hold a DISCUSS over "not the best choice".

Not to mention that this is only a Proposed Standard discussion; perfection not required.

I don't consider myself enough of a subject matter expert to comment on the technical issue itself.

Regards
    Brian

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Jun 2020 12:32:56 -0400

Brian:

I disagree with your characterization of the situation.  RFC 5280 talks about Subject Alternative Names, and the rfc822Name is used for an email address.  This specification puts something other than an email address in that field, and I raised a concern when I reviewed the document.  Other name forms are explicitly accommodated by otherName, and in my review, I suggested using otherName instead of rfc822Name.

I observe that jabber IDs have the same syntax as an email address, but they are not carried in rfc822name because the semantics are different.

One cannot send email to the character string in this specification, so it should not be carried in the rfc822name.

Russ

> On Jun 19, 2020, at 1:11 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Ben,
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Jun 2020 08:22:43 +1200

Hi Russ,

I think everyone agrees that it's bending the purpose of a protocol element, for pragmatic reasons, and it isn't something I particularly like either. But it was a pragmatic choice made after discussing the alternatives.

Regards
   Brian

---

From: Sean Turner <[email-masked]>
Date: Fri, 19 Jun 2020 23:34:19 -0400

I am coming at this way late, and I apologize for that.

After reviewing draft-ietf-anima-autonomic-control-plane, I think that putting ACP Domain Information in rfc822Name is a bad idea. After reviewing the mailing list for rfc822Name-related messages, I think I may have graduated to thinking that putting ACP Domain Information in rfc822Name is a very risky deployment strategy, and I may have even graduated to thinking it is harmful to others in the Internet ecosystem.

rfc822Name is meant to convey “an Internet mail address” [RFC5280]. ACP Domain Information is not that so it seems, at least to me, like rfc822Name is not the right place to put ACP Domain Information.

My next thought was that others have defined values for otherName, which is the extension point in X.509 to support name forms not envisioned in 2002, so what is special about anima that they should to “squat" on an existing name form? The rationale, which seems oddly out of place in a normative section, did not really make sense to me, especially in the context of IDevID and LDevID. For example, the “Rfc822 addresses have become standard identifiers of entities in many systems, including the majority of user identification in web or mobile applications, ...” might well be true for humans, but it is not true for devices. Humans can only remember few identifiers (e.g., an email addresses) and type them correctly over and over. The situation here is vey different; a device is identified (and authenticated) by the IDevID and LDevID. The sense I got from the rationale boils down to: we need some certs and we think we can get them if we put our “name" in a commonly supported field.

Regardless of whether public CAs or enterprise CAs issue the certs, what seems to be getting lost here is that running a CA is more than just running a server and signing a bag of bits. If you are going to run a CA that is trusted beyond your organization, a lot of policies and procedures are followed to make it trustworthy. You need to write a CP (Certificate Policy) and CPS (Certification Practice Statement) [RFC3647], get lawyers to review it and probably write section 9 (Other Business and Other legal Matters), and you are going to need to get regular audits from a reputable firm. To limit your liability, you are also likely going to need to have Subscriber and/or Relying Party agreements.

As far as private CAs goes, I am not trying to say what is hard and what is not, but both Microsoft CA and OpenSSL support arbitrary data being placed in a subjectAltName.otherName:
- MS: https://docs.microsoft.com/en-us/windows/win32/api/certenroll/nn-certenroll-ix509extensionalternativenames
- OpenSSL: https://www.openssl.org/docs/man1.0.2/

If you are relying on a public CA, I think this is a very risky deployment strategy because this I-D is saying that it is okay to request a name that that has different semantics than the name that you are asking to be certified. Consider whether:
- a CA could reject the request outright?
- a CA would revoke an already issued certificate after determining that the request did not comply with the CP, CPS and/or Subscriber agreement?
- an RP could later claim damages because the Subscriber did not request the certificate in good faith?

I also think that there is some potential for negative impacts on others in the Internet ecosystem based on this I-D, at least in the light of the above. For example, maybe just maybe somebody manages to get 100K IDevID certificates from a public CA. That public CA decides that those certificates were mis-issued and revokes them as their CP/RP agreement allows (or even requires). An entity that has to download and then slog through the bigger-than-normal CRL (Certificate Revocation List) is adversely affected. Maybe that CA only supports OCSP (Online Certificate Status Protocol), but the OCSP Responder is fed by a CRL, the CA still needs to store and process the bigger-than-normal CRL to pump out the OCSP responses so the CA is also adversely impacted.

I know I am not providing an alternative solution here, but maybe we can do that in another thread.

spt

> On Jun 16, 2020, at 22:44, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Brian, Michael,
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 20 Jun 2020 16:48:14 -0700

Hi Brian,

> (Back on line after a couple of days spent moving apartments.)

(and me after getting slowed down by being sick)

> Yes, but that was exactly the reason we had the discussion a year ago.

I think the expansion of the "we" is important, here -- who did you have in
mind?

> If you are saying that one of the criteria in https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc applies, that's a different matter, of course. But really, no AD sh…

Sorry, that was the second round of Discuss and my politness filter may
have been overactive.  Allow me to rephrase:

I think that the use of rfc822Name in this document is inconsistent with
the specification for that field given in RFC 5280.  I do not believe that there
is IETF consensus (specifically, including the IETF PKIX community, e.g.,
the LAMPS WG) for this deviation from the RFC 5280 behavior, and it is not
documented (and consensus obtained for it) as such a deviation from RFC
5280.

I believe there are several ways in which the necessary functionality for
this specification can be obtained that remain consistent with RFC 5280;
specifying the use of any of them would suffice to resolve the Discuss
point.  The "smallest diff to the text" option would be to define an
otherName OID to carry the same contents currently specified for
rfc822Name, but other options involving splitting the semantic components
into EKU/iPAddress SAN/extension/etc. are possible.  I could probably even
accept a non-normative note saying that some legacy deployments used the
rfc822Name field, though given Sean's review there would probably need to
be a pretty strong disclaimer of the risks of doing so.

[one more note at the end]

> > it's making use of, but the refocus on the "running code" aspect is

Thinking about this a bit more, it seems like it would be doable (and, more
importantly, testable) to require that if the otherName (or whatever) is
present, there MUST NOT be an rfc822Name present.  Which doesn't
necessarily help with the "need to implement" bit for sites that use
rfc822Name, of course, but should avoid the worst of the risks for when two
sources of data don't match.

-Ben

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Jun 2020 14:41:43 +1200

Thanks Ben. It's important IMHO to be precise about technical objections and your statement below is precise. As a non-expert, I'll refrain from technical comment.

Regards
   Brian

> I think the expansion of the "we" is important, here -- who did you have in

Well, I guess it was between you and the WG, but prior to IETF-wide review.
My understanding was that we'd reached an unhappy compromise, but apparently
not.

    Brian

---

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

Russ Housley <[email-masked]> wrote:
    > One cannot send email to the character string in this specification, so
    > it should not be carried in the rfc822name.

You can send email to that character string if you configure the MX.
It was designed specifically to accomodate that.

I objected at the time: I thought it was a stupid feature, that no sensible IKEv2 daemon
was going to have to send/receive email.

But, Toerless was paranoid that if we did anything at all out of the
ordinary, that the corporate CA people, in order to protect their fiefdom,
would freak out and throw some huge roadblock in the way of deploying the ACP.

And, now have an ACME method past WGLC that does certificate validation by
SMTP.

---

From: Russ Housley <[email-masked]>
Date: Sun, 21 Jun 2020 12:36:06 -0400

> On Jun 21, 2020, at 12:28 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Looking at the email certificate enrollment work in the ACME WG (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device that knows the private key could participate in such a protocol.  How do you see it working?

Russ

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 21 Jun 2020 10:16:56 -0700

> would freak out and throw some huge roadblock in the way of deploying the ACP.

I note that the -24 discusses creating a single mailbox rfcSELF@<domain>,
which receives mail for *all* ACP identities in the domain, yet we are
in other parts of the document claiming that these identities are distinct
and in many cases will be granted different authorizations.  If these
identities are supposed to be equivalent in the "RFC 822" sense, then it
seems inconsistent to use the rfc822Name field (which sees them as
equivalent) yet treat them as distinct entitites.

-Ben

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Jun 2020 05:08:17 +0200

> make.  If WGs had such authority then why bother with cross-area review?

I probably still don't understand process well enough for a WG chair, but
given how i am just here as an author ;-):

Cross-WG review during IETF review time is fine but it looks to me as
if this point in Russ' review does not raise to the level of SEC AD
review consideration. Aka: Russ can perfectly have an opinion about
encoding preferences, and so can have other WG groups, but we
need to use real technical arguments to make our choices. There
are 15 bullet points justifying and explaining the choice but the
feedback reveived does not take any of them into account.

> Discuss-level concern about rfc822Name usage along with the promised

Yes. I felt bad for you investing that much amount of work into an
alternate proposal without having a discussion about this point.
I do not remember if the crucial points why binary enoding was
a inferior and ecossytem overhead choice was in the drafts you read
or if i added/improved them in reply to your suggestion. Its
now in sectin 6.1.2 explanation points 2.2, 2.3, 2.4, 2.5, 3.2, 3.3, 3.5.

> out of that review that are still pending.)

It is still not a technical discussion to simply reply to a list of 8
points "this is not compelling".

As i asked in the reply to Russ: Show me RFC text that would prohibit what we do.
Show me security issues. SHow me any technical issues. Show me how this
concern is anything more than an opinion that should not raise to the level
 of SEC AD DISCUSS block.

> some consideration to matters of expediency.

My understand is that i have have not seen a technical argument for the
DISCUSS, but just a suggestion for encoding preference.

> openssl at this point and would presumably be writing my own, in this

And ossification in the wide range of vendor specific software that
ACP ha to deal with is one reason to not use an encoding choice
that maximizes the amount of ecossytem changes.

> the IETF, and the latter seems to have high overlap with point (1).

So far, there is no defined integration ACME and ANIMA. We did discuss
this in a side meeting last year, but didn't continue, and i would not
want to bring this discussion into the fold now because the whole premise
of ACP was to be standalone private networks where the only reason to
look into any type of public PKI is to help outsourcing TA work overhead,
and that does not need to be a typical PKI anyhow.

Not saying that i wouldn't like to see ANIMA to integrate with ACME,
but thats not a concern for this document but at best for followup work.

> it's making use of, but the refocus on the "running code" aspect is

"violates the rules set down by the specification for the technology"

??

I have not seen any supporting evidence for that. the rfc822name is
a perfect rfc822name formatted string.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Jun 2020 15:37:58 +1200

>>>> We already had this debate.

....
> a perfect rfc822name formatted string.

Well, more than that. It's a perfectly valid email address, accepted by conformant SMTP servers.

Yes, it does lead to a delivery failure, but it doesn't just *look like* an email address, it *is* an email address. Why is it misuse of rfc822name to express a valid email address that has no mailbox behind it? Is this in any way a security vulnerability? What does it break?

I still don't see how this qualifies as a DISCUSS issue. I do see that it is unaesthetic. I do see how it meets several of the DISCUSS non-criteria at https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc

   Brian

Subject: Delivery Status Notification (Failure)
From: Mail Delivery Subsystem <[email-masked]>
To: [email-masked]
Date: Tue, 23 Jun 2020 13:34:45 -0700 (PDT)

** Address not found **

Your message wasn't delivered to [email-masked] because the domain acp.example.com couldn't be found. Check for typos or unnecessary spaces and try again.

The response was:

DNS Error: 111832 DNS type 'mx' lookup of acp.example.com responded with code NXDOMAIN
Domain name not found: acp.example.com

Subject: Re: [Anima] representing ACP info in X.509 certs
From: Brian E Carpenter <[email-masked]>
To: Stephen Kent <stkent=[email-masked]>, "Owen Friel (ofriel)" <ofriel=[email-masked]>, Eric Rescorla <[email-masked]>
Cc: Anima WG <[email-masked]>, [email-masked]
Date: Wed, 24 Jun 2020 08:34:38 +1200

Regards
   Brian Carpenter

On 24-Jun-20 03:46, Stephen Kent wrote:
> 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.

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

> Steve

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 27 Jun 2020 07:40:56 +0200

Russ,

Top posting re. your ACP vs. ACME question.

ACP rfc822name are meant to be under control of the ACP network operations.
aka: the ACP registrars could be controlling [email-masked] mailboxes using
ACME S/MIME to get [email-masked] certificates or IMHO easier control
the acp.example.com MTA.  Just no need/benefit to do this now IMHO:

An ACP is a private network which is ideally isolated from other
ACP networks by use of private TA. Using the ACME rfc822name scheme would
IMHO create a lot of attack components (all the MTA in the mail path
and domain names) if used acros the Internet - without benefits for
ACP. Of course, if it was all a private ACME setup within an enterprise,
and using mailboxes and ACME is a popular choice - sure, why not.
But for private CA setups there are existing IMO easier options
(private CA VMs using EST or the like).

IMHO public ACME CAwith S/MIME authenitcation could  make sense 
in the future to enable authentication across different ACP domains.

Any network has links into other domains and today they are usually
unauthenticated, that could be solved IMHO fairly easily.

"private" CA of ACP domain , lets call it acpCA signs all ACP certs.
Its own cert is not self-signed, but signed by ACME CA via S/MIME,
 maybe email is [email-masked] (no ACP IPv6 address in it)

Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA.
After IKEv2 authenticates neigbor the followup ACP domain membership
step checks if the TA of the peer is acpCA. If yes, then peer
becomes ACP member, otherwise we have an authenticated signalling
channel to an interdomain / different CA peer. And that of course
would enable better/secure auto-configuration of such interdomain
links.

This gives me good mix of security: Its still only relying on
well controlled private TA to get into ACP, but also doubles
at less secure but best available "Internet/Interdomain"
authentication.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 27 Jun 2020 17:02:06 +0200

Russ,

...getting to backlog...

inline.

> I disagree with your characterization of the situation.  RFC 5280 talks about Subject Alternative Names, and the rfc822Name is used for an email address.  This specification puts something other th…

I think i stated often enough now that the ACP domain information is
meant to be a both syntactically and semantically correct electronic
mail address. Maybe you can provide technical reasons why you think it is not.

Is there some degree of uglyness ? Indeed, all the uglyness comes
from seeing how typical electronic mailbox handling could be
supported:

rfcSELF is a prefix to de-conflict the mail box local-parts
from other classes of entities when they share the same domain part.

Think [email-masked] for contractors (temp workers) to
keep the nice [email-masked] free.

Likewise area51.research as a suffix is quite comparable in syntax
and semantic to department names you can see in local parts.

> I observe that jabber IDs have the same syntax as an email address, but they are not carried in rfc822name because the semantics are different.

Sure, but thats because in that solution you want to be able to imply
different application scopes for potentially the same entity, aka: reuse the
same entity name (local-part@domain) for email and jabber.

In our case we are coming up with email address names for new entities
that would fit well into existing email address name spaces already existing.

> One cannot send email to the character string in this specification, so it should not be carried in the rfc822name.

First of all, you can if you want to, and secondly, i contest that
it is a requirement to be able to do that if the recipient doesn't
need to support it. Think about [email-masked].
You do want to make sure though that you are in control of
the electronic mail address though, and that is given for ACP
addresses.

Example: in WiFi access with roaming you also use
local-part@domain as entity identifiers, and some seem to
be using certificates with rfc822Name. And to the best of
my understanding, nothing on those solutions depends on
the actual use of mail boxes. Maybe in those places where like
in ACME you can enroll by some challenge of ownership of
the mailbox, but that could equally be just web based if it
exists at all in a particular instance.

Cheers
    Toeress

-- 
---
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Sat, 27 Jun 2020 11:52:20 -0400

Toerless:

I think Brian actually made my point.  While the filed contains an email address, using it as such would result in a delivery failure.  The private key holder cannot be reached by this address.

Russ

> On Jun 27, 2020, at 1:40 AM, Toerless Eckert <[email-masked]> wrote:
> 
> Russ,
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 27 Jun 2020 11:56:43 -0400

Toerless:

Your example is making my point: [email-masked] <mailto:[email-masked]>.  Such an email address should not appear in a certificate.  It does not name the private key holder.

Russ

> On Jun 27, 2020, at 11:02 AM, Toerless Eckert <[email-masked]> wrote:
> 
> Russ,
> 
> ...getting to backlog...
> 
> inline.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Jun 2020 08:47:46 +1200

> I think Brian actually made my point.  While the filed contains an email address, using it as such would result in a delivery failure.  The private key holder cannot be reached by this address.

I don't see a requirement in RFC5280 that the email address in an rfc822name must be reachable, or that it must belong to the private key holder.

   Brian

---

From: Russ Housley <[email-masked]>
Date: Sat, 27 Jun 2020 17:27:46 -0400

> I don't see a requirement in RFC5280 that the email address in an rfc822name must be reachable, or that it must belong to the private key holder.

We seem to be interpreting RFC 5280, Sections 4.1.2.6 and 4.2.16 differently.

4.1.2.6.  Subject

   The subject field identifies the entity associated with the public
   key stored in the subject public key field.  The subject name MAY be
   carried in the subject field and/or the subjectAltName extension.  ...

4.2.1.6.  Subject Alternative Name

   ...

   When the subjectAltName extension contains an Internet mail address,
   the address MUST be stored in the rfc822Name.  The format of an
   rfc822Name is a "Mailbox" as defined in Section 4.1.2 of [RFC2821].
   A Mailbox has the form "Local-part@Domain".  Note that a Mailbox has
   no phrase (such as a common name) before it, has no comment (text
   surrounded in parentheses) after it, and is not surrounded by "<" and
   ">".  Rules for encoding Internet mail addresses that include
   internationalized domain names are specified in Section 7.5.

Section 4.1.2 of RFC 2821 provides the ABNF for the Mailbox.

RFC 2821 says:

   As used in this specification, an "address" is a character string
   that identifies a user to whom mail will be sent or a location into
   which mail will be deposited.  The term "mailbox" refers to that
   depository. ...

So, the mailbox is the place that email gets sent to.

Russ

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 28 Jun 2020 00:46:40 +0200

Russ, i said:

> First of all, you can if you want to,
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Aka: Yes, if an ACP admin thinks ACME style challenge/reply
email authentication mechanism is useful, then he can of course
set up those email addresses accordingly. I did reply to that
point exhaustively in my reply about the ACME email mechanism.

 Why do you ignore that answer ?

> and secondly, i contest that it is a requirement to be able
> to do that if the recipient doesn't need to support it.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Think about [email-masked].

Where in rfc5280 or any other generic RFC about certificates does
it say you MUST have a mailbox that is reachable ? Where does it
say that all certificiates with rfc822Name must be email boxes
that support ACME email style challenge-reply about the email address ?
I think this is a non-existing requirement against email addresses.

Of course, [email-masked] can have a certificate with
that rfc822Name. It just can't use the ACME mechanism to be
generated. But the signed mails sent from that address can be
authenticated.

Or there are never emails, because the email address just serves
as identifier of an entity such as in wifi roaming identification
and authentication. In that case you are not authenticating
e.g.: password ownership for the email address via actual emails
but via AAA protocols against a DNS domain known AAA server
for the domain part of the email address.

If you want to write a standards track RFC that all email addresses
used in any X.509v3 certificate MUST support an ACME style 
challenge/reply email, then please do that, and seee if you get
thast through. If would invalidate a lot of solutions like
those wifi roaming ones. It WOULD NOT invalidate the ACP
solution, because as said (no several times) the ACP solution
can perfectly be set up to support this. It just does not
need to.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Jun 2020 15:58:21 -0700

I'm not Russ, but I don't take his point to be about ACME one way or the
other.

Rather, I take his point to be (as he just said in his response to Brian)
that while this is *formatted* as an e-mail address, it does not in fact
correspond to something to which e-mail can be delivered and therefore does
not match the semantics of RFC 5280.

Taking a step back from the substantive issue, it seems to me that to the
extent to which their is debate about the meaning of 5280, this is a
discussion which cannot be resolved entirely on this list, but instead
needs to involve the LAMPS WG.

-Ekr

On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert <[email-masked]> wrote:

> > I think Brian actually made my point.  While the filed contains an email
> address, using it as such would result in a delivery failure.  The private
> key holder cannot be reached by this address.
>
> Russ, i said:
>
> > >> Looking at the email certificate enrollment work in the ACME WG
> (draft-ietf-acme-email-smime-08), I have a hard time seeing how the device
> that knows the private key could participate in such a protocol.  How do
> you see it working?
> > >>
> > >> Russ
> > >>
> > >
> > >
> > >

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 27 Jun 2020 16:13:52 -0700

My apologies for commenting before having caught up on the whole thread
(I've been pretty sluggish all week and don't want to get even further
behind.)

> needs to involve the LAMPS WG.

This has been a key point that I've (apparently) been failing to make very
well so far.  E.g., while the ANIMA WG has presumably reached consensus on
the use of rfc822Name years ago, I think we also need consensus from LAMPS
before we can be confident that there is IETF consensus.

Also, making even another step back, it seems that there is a key issue of
the CA model in play here, namely "know what you sign".  If we are asking a
CA to sign an rfc822Name, which the CA treats as having email semantics,
but we assign different semantics to that name, then the CA is not actually
in knowledge of what it's signing.  Accordingly, the CA incurs significant
(e.g., legal and financial) risk by making those signatures, and defining
the field in this way gives the impression that we are trying to make an
end-run around CA policies.

-Ben

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 28 Jun 2020 02:06:54 +0200

Thanks, Russ, inline

>    carried in the subject field and/or the subjectAltName extension.  ...

Yep. For purpose of ACP, we use rfc822Name, but the entity may get
from registrar/CA other names too, such as any pre-existing, however
formatted SN.

>    the address MUST be stored in the rfc822Name.

Yes. ACP does that.

>    The format of an
>    A Mailbox has the form "Local-part@Domain".

Yes. ACP does that.

>    Note that a Mailbox has

Yes, ACP does that.

> Section 4.1.2 of RFC 2821 provides the ABNF for the Mailbox.

Yes, ACP matches that. Actually, when i did the ABNF, i had to go
through a couple of RFC becaue 2821 was superceeded and i think i picked
as references the now normative one, but have to go back and remember details.
No actual change in the syntax AFAIK since rfc2821.

> So, the mailbox is the place that email gets sent to.

Do you think that this sentence makes an address of [email-masked]
an invalid email address given how it does not receive email ?

And please do not conflate this discussion with the use in certificates,
your discussion points about rfc2821 are non-considering any
certificate work, as rfc5280 does not attempt to redecine anything.

Would you also like to legislate what "user" means ? E.g.: would
[email-masked], valid email address in your reading or does
a user have to be a human ?

In any case: ACP email address can perfectly well have mailboxes,

You also did not repy to my expamples about other systems where
email addresses are primarily used for non-mailbox purposes
but still encoded in rfc822Name. I have seen no outlawing of
this practice through IETF documents.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 28 Jun 2020 02:09:22 +0200

Thanks, Eric, inline

> not match the semantics of RFC 5280.

And i did repeatedly explain how this is not true. 
The ACP operator can perfectly well set up mailxobxes if he desires to.
The whole question circles around the use of email addresses primairily
for purposes other than sending to mailboxes, and i gave other
examples where this is common industry practice and also uses 
certificate rfc822Name.

> needs to involve the LAMPS WG.

Let me answer this to Ben.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Jun 2020 17:18:46 -0700

> And i did repeatedly explain how this is not true.

Well, I understand you think you explained it, but unfortunately I don't
find that argument persuasive, nor, I suspect, do others.

And if ACP required the operators to do so, I think that would also resolve
this issue from an IETF perspective (although you still would likely not be
able to get publicly verifiable certificates for this purpose, at least
from any CA in the Mozilla root program, for the reasons I indicated
previously).

> examples where this is common industry practice and also uses

I don't see how that makes this a practice which we should be endorsing.

-Ekr

> > > > > ACME S/MIME to get [email-masked] certificates or IMHO
> easier
> > > control
> > > > >>> I objected at the time: I thought it was a stupid feature, that
> no
> > > sensible IKEv2 daemon

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 28 Jun 2020 02:45:29 +0200

[Adding Barry and a few more folks]

Ben, Russ:

RFC5280 does not redefine anything about email addresses. It solely
refer to RFC2821 definitions of them. Russ' last email on this
thread explicitly reconfirmed that his concern is purely about
use of email addresses in anima wrt. his reading of RFC2821. 
I think he is inventing new legislation what is and what is
not a valid email address.

>From that perspective i ask you to consult with Barry which the
appropriate IETF WG is that has the expertise to provide input into
how to interpret RFC2821, the RFCs that obsoleted it, or in
general what does and what does not constitute a semantically
correct email address. Maybe emailcore WG. I don't know. Barry ?

There is ample explanation how what ACP uses as an email addrss
is in our opinion perfectly valid syntactically and semantically,
most of the argumens are in the numbered list in section 6.1.2
of the ACP draft. I have not seen any substantial technical
argument invalidating what is written there.

I have repeated written that ACP email addresses CAN HAVE
an actual mailbox associated with them when desirable, but
that like other common use-cases of email addresses such as
wifi roaiming authentication, where also rfc822Name are used to
certify ownership of such addresses, the main purpose of the use
of these addresses is not that of sending or receiving email.
I have pointed to examples like [email-masked] which also
is a typical example of a valid email address that arguably could
be interpreted to have no mailbox associated with it.

The ACP draft also well specifies how even in he absence of
a configured physical mailbox, the email address itself is
assigned such that it is under the control of the entity (ACP)
it identifies. Such that no one else but his entity could own
a mailbox for that email address.

If LAMPS is interested to define additional constraints on
email addresses required to make them legal to be put into PKIX
rfc822Name attributes, i think thatss thats group perogative,
but please:

Such future additional constrain work can not be used to hold
up progressing ACP now, especially not when it is just
personal prefernces for encoding without any technical
eplanation as to the harm the choice could provide.

Aka: If there i anything reasonable to ask LAMPS now, then it is
not to legislate what is a valid email address, but at most
to come up with possible harm of putting particular email
addresses into rfc822Name.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 28 Jun 2020 02:54:33 +0200

> from any CA in the Mozilla root program, for the reasons I indicated

FInd the email in the thread where i eplained to Russ how a public CA
is useless if not dangerous for what the ACP does right now, but it
could be quite useful in future extensons, such as for interdomain
auhentication via ACMPE S/MIME.

Please understand the use case first before thinking that apply
Internet public PKI requirements is always the right think to do.
This version of ACP is solely for private networks and effectively
for private PKI. We went through all that review together, and 
you and Ben approved of that text.

> I don't see how that makes this a practice which we should be endorsing.

Again, give me any technical reasoning. show me any possible harm.
All i am seeing now is a choice of preference from people who where
not active in the working group, and they had 5 years time. And i think
anyhthing short of showing possible harm should really be the WG
decision.

Especially when i continuously bring technical arguments that nobody
seems to bother to read, at least hey are never acknowledged. Such
as the reasons for differet choice of preference between e.g.:
other uses of email addresses picking a new otherName vs. our
solution preference not to do tht.

And even more the harm that another choice would create for the ease
of adoption of the solution. We have several points how unnecessary
churn in encoding creates much more of harm and pain in a highly
fragmented, ossified environemnt such as that of wide area/enterprise
routers & switches than in your backyard of highly agile, often
vertically integrted cloud/web software. Please do not ignore the
the requirements of the ecosystem when expressing preferences.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 27 Jun 2020 17:57:45 -0700

> Internet public PKI requirements is always the right think to do.

I didn't say any such thing. I merely observed that it would not be
compatible
with the requirements those CAs operate under. That's why I put it in
parentheses.

-Ekr

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 28 Jun 2020 03:11:14 +0200

On Sat, Jun 27, 2020 at 05:57:45PM -0700, Eric Rescorla wrote:
> compatible with the requirements those CAs operate under. That's why I put it in
> parentheses.

Thanks.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Jun 2020 15:09:52 +1200

Hi Eric,

On 28-Jun-20 10:58, Eric Rescorla wrote:
> I'm not Russ, but I don't take his point to be about ACME one way or the other.
> 
> Rather, I take his point to be (as he just said in his response to Brian) that while this is *formatted* as an e-mail address, it does not in fact correspond to something to which e-mail can be delivered 

It might do, simply because it is so formatted.

> and therefore does not match the semantics of RFC 5280.

RFC5280 does not require such a mailbox to exist. Is there another normative document, e.g. a BCP, that does require one? It's entirely possible that the authors of RFC5280 assumed that such a mailbox would exist, but this is not written anywhere that I can see. So IMNSHO, this objection to the ACP draft is attempting to hold it to a standard that isn't documented.
 
> Taking a step back from the substantive issue, it seems to me that to the extent to which their is debate about the meaning of 5280, this is a discussion which cannot be resolved entirely on this list, but instead needs to involve the LAMPS WG.

That may be true, but it's not ANIMA's fault and the discussion first arose last year, so why hasn't LAMPS already considered it, if it's important enough to continue obstructing ANIMA's progress?

  Brian

> 
> -Ekr
> 
> 
> 
> 
> On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert <[email-masked] <mailto:tte@cs..fau.de>> wrote:
> 
>     > Think about [email-masked] <mailto:[email-masked]>.
>     Of course, [email-masked] <mailto:[email-masked]> can have a certificate with
>     > > On Jun 27, 2020, at 1:40 AM, Toerless Eckert <[email-masked] <mailto:[email-masked]>> wrote:
>     > >
>     > > Russ,
>     > >
>     > > aka: the ACP registrars could be controlling [email-masked] <http://example.com> mailboxes using
>     > > ACME S/MIME to get [email-masked] <http://example.com> certificates or IMHO easier control
>     > > the acp.example.com <http://acp.example.com> MTA.  Just no need/benefit to do this now IMHO:
>     > >
>     > > maybe email is [email-masked] <mailto:[email-masked]> (no ACP IPv6 address in it)
>     > >
>     > >>> On Jun 21, 2020, at 12:28 PM, Michael Richardson <mcr+ietf@sandelman..ca <mailto:[email-masked]>> wrote:
>     > >>>
>     > >>>
>     > >>> Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>     > >> [email-masked] <mailto:[email-masked]>
>     > > [email-masked] <mailto:[email-masked]>
> 
>     -- 
>     ---
>     [email-masked] <mailto:[email-masked]>
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Russ Housley <[email-masked]>
Date: Sun, 28 Jun 2020 10:32:37 -0400

> On Jun 27, 2020, at 6:46 PM, Toerless Eckert <[email-masked]> wrote:
> 

You and Michael have said that MX records could be set up, but Brian says that will lead to delivery failures.  And then Ben pointed out that a single mailbox rfcSELF@<domain> is used for all ACP identities in the domain.  That has not been resolved.

>> to do that if the recipient doesn't need to support it.

I have explained reasoning in a note yesterday in response to Brian, and it had nothing to do with ACME.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sun, 28 Jun 2020 10:36:34 -0400

> On Jun 27, 2020, at 8:06 PM, Toerless Eckert <[email-masked]> wrote:
> 
> Thanks, Russ, inline
> 

It is clear that [email-masked] has the syntax of an email address, but there is not corresponding mailbox.  For that reason, it should not appear in a certificate.  It is the the email address of the subject of the certificate.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sun, 28 Jun 2020 10:47:51 -0400

Brian:

The point of a certificate is to bind the public key to the identity of the private key holder.  The certificate supports many different forms of names to support many different protocols.  The rfc822name is used to bind to an email address.  And, something else is going on here.  That is why I recommend otherName instead of rfc822name.

I think that everyone understands that at this point.

Eric:

Please change the write-up for this document.  It currently says:

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No. There was unanimous support for this work and nobody raised any objections.
This is no longer the case.

Russ

> On Jun 27, 2020, at 11:09 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Eric,
>

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 28 Jun 2020 18:11:49 +0200

On Sun, Jun 28, 2020 at 10:47:51AM -0400, Russ Housley wrote:
> Brian:
> 
> The point of a certificate is to bind the public key to the identity of the private key holder.  The certificate supports many different forms of names to support many different protocols.  The rfc822name is used to bind to an email address.

How do you think IETF should decide on what is a semantic correct
email address ? RFC5280 simply inherited the non-crypto definitions
of email address/mailbox.

Do you think it is appropriate for you to recommend blocking progress
of a document through IESG review based on your interpretation what
does and what does not constitute a semantic correct email address ?

Do you think that there are rfc2821 email addresses that are
semantically correct if not used in a certificate, but that are
not semantically correct for use in rfc5280 certificates ? If so,
can you please explain how such a differentiation would be justified
by existing RFC text ?

If you do not think that there is a semantic correct email addresses
outside and inside of certificate/rfc822Name use, how then would
it be appropriate for you, Ben or LAMPS to decide on what is and
what is not a semantic correct email address.

> And, something else is going on here.

Are you saying the addresses are (1) semantic correct email addresses AND
something else is going on, or are you saying (2) they are NOT
semantic correct email addresses AND something else is going on.

If you are saying (1), we are back to the above discussion of
the standing of how to decide what does and what does not
consitute a semantic correct email address.

If you are saying (2), i fully agree, but i would need an explanation
of how such "something else" would invalidate the use of such
email addresses in rfc822Name, because i see no further requirements
against email addresses in rfc822Name other than what you showed
in a prior mair on this thread. 

If a terminal is assigned an email address of
"[email-masked]", and the software says to the
user "you are sitting in Room17 on Terminal5", because the
software expected a particular formed local part of its
email address and parsed it, that is something else going on.

If the same email address is then use together as an
identifier together with a password for the terminal to
access some resources, oh, like a library database, that is 
also something else going on. 

This is pretty much what ACP does. What is IMHO is NOT going
on here is that these additional aspects render
[email-masked] into a non semantic correct
email address. They just do more with it.

> That is why I recommend otherName instead of rfc822name.

No, if you would just recommend an alternative that would be great,
but you are blocking progress of a document that has a lot of
in our opinion crucial explanations how that alternative would
create more use-case harm than the solution choosen in the document.

> I think that everyone understands that at this point.

I do not understand how a recommendation like yours can raise to
a blocking DISCUSS in an IESG review.

> This is no longer the case.

So, it is not a recommendation you are voicing, it is instead
"extreme discontent". 

I wonder what rules of IETF are for betting how such "extreme miscontent"
has to be technically founded or just needs to be taken into account
without suficient technical argument. I think you have provided
no clear technical reasoning for:

- How does the documents choice cause more harm than the alternative
  proposed for the use-cases or any other possible victims ?
- How is the choice in violation of any relevant RFC ?
- How are the email addresses not syntactic and semantic correct addresses according to rfc2821 ?
- How are otherwise statements like "i do not think this is the right thing" and
  "there is something else going on here" sufficient arguments for blocking
  IESG progressing the document.

Cheers
    Toerless

-- 
---
[email-masked]

---

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

> It is clear that [email-masked] has the syntax of an email address, but there is not corresponding mailbox.  For that reason, it should not appear in a certificate.  It is the the email address of…

Ok, i think this simple example allows me maybe to understand the process better.

So, if i was to write a target normative RFC explaining for example 
certificates for "customer communications" departments of example.com that would
result in creation of certs with rfc822Name [email-masked].

This draft passes 5 years through WG and all IETF/IESG review except SEC review.

What now are the criteria by which your opinion should be vetted as a blocker
for IESG approval of the document ?

I for once received numerous email in private that it is impossible to argue
opinions of security people in IETF technically, just because of the weight that their
names carry with IESG, so i shouldn't even try technical arguments. And i fear this is
true, and some of the other emails here (not from you) also indicate this to me.

If not, then i would like to hear what you think the process should be.

If this is  the process, then i should obviously stop making technical
arguments, accept defeat and move on. Hopefully we will at least be allowed
to document in the RFC how easier implementable and deployable solutions
where unacceptable due to ... understanding of the required semantic of
rfc822Name content. Otherwise we would loose the whole discussion here.

I already feel that the process is injust because i seem to
have to prove that what we are doing is not in violation of RFC/semantics,
which to me sounds like i have to prove our draft is "innocent", whereas
i was under the assumption that the burden of proof was opposite.

Wrt to the technical argument:

[email-masked] is an interesting example, because i hate receiving these
emails, so i would LOVE to see a normative RFC saying that these type of
email addresses MUST NOT get certificates. However, technically i think that
is not defensible, because obviously (to me) its perfect valid for a
mailbox to not receive or not to send emails. Its to me just a controlled subject
with a name/address.

And customer harrasment departments are of course also
interested to be protected from phishing and the like, so they will
of course also use certificates for mails from [email-masked] as soon
as enough customers would understand security (*sigh*). And i am willing
to take any bet with you, that there will be nothing from the IETF that
normatively says this should not be done. 

Cheers
    Toerless

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Jun 2020 09:49:34 -0400

> a blocking DISCUSS in an IESG review.

I was asked to go a review, and I did so.  As I said, I am quite sure that you and everyone else that is reading this thread understands the concern at this point.

In my opinion, and the opinion of a few others that have spoken on this list, the use of rfc822name is harmful.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Jun 2020 09:59:09 -0400

> On Jun 28, 2020, at 1:01 PM, Toerless Eckert <[email-masked]> wrote:
> 

No.  I go not agree.  The [email-masked] mailbox is not ever used to communicate with the party that holds the private key.  So, it should not be bound to the subject public key in a certificate.

Russ

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 29 Jun 2020 16:21:24 +0200

> No.  I go not agree.  The [email-masked] mailbox is not ever used to communicate with the party that holds the private key.  So, it should not be bound to the subject public key in a certificate.

Why can [email-masked] not have the private key for
the certificate which has [email-masked] in its
rfc822Name ?

Are you excluding the option for any validation procedure
that does not include an actual ?challenge? email to
the email address ? Remember that in a private PKI
environment ALL names in a certificate could be
assigned to the entity based on a validation that
by itself may not show up in the certificate at all. E.g.:

When i become employee of a company, someone might
see my drivers license, but the company PKI generated
cert for me in that enrollment process would not
have any info from that drivers license, but just
my name in the SNand company email address in the
rfc822Name SAN.  On a USB TPM stick. To sign my email,
or whatever else.

Oh, and i was hired to be responsible to send harrassment
emails to customers, so i get a second USB TPM stick
to use specifically for this job role and it has
only rfc822Name email address with [email-masked].

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jun 2020 18:10:04 +0200

Just had a call with Russ and Barry (thanks Russ, Barry), and here is
what transpired, and it comes with a Q to the ANIMA WG wrt. to
solution options (see below). Hopefully Russ/Barry will correct me if i
misrepresent anything.

Russ and Barry agreed that a solutions where email addresses are not
primarily intended to be used for actual emails (e.g.: using SMTP/RFC5321)
may be something found in the wild, but in their opinion, it would create
harm (to i guess the Internet email system), significant enough to warrant
an IESG DISCUSS if such use was to be defined into an Internet Standard.

If i understood it correctly, the choice of otherName by previous solutions
similar might have also been influenced by the same rejection to use rfc822Name
It sounded to me from the call as if email address/rfc822Name  might have
been desired to be used first by e.g.: XMPP but then they had to move to
an otherName (RFC3920 i think) because of resistance to get that standardized.
That at least would be a detail i was missing from the prior explanations on
this thread.

I continue to disagree, but i think the resolution of this basic
argument would create an inacceptable timeline to progress ANIMA,
so i do not want to afford this discussion any longer for the ACP draft.
[ Hopefully i can get back to after ACP is done because i still think it
is quite fundamental. ]

a) Russ promised me a text stub or pointers thereto necessary/sufficient to define a new
   use (and i guess IANA registration). Probably something similar to
   what is e.g.: found in rfc8398.

   I think IANA registration is here: https://www.iana.org/assignments/smi-numbers/smi-numbers.xml
   See e.g.: id-on-SmtpUTF8Mailbox, 
   registration procedure: spec required, expert: Russ Housley

b) I brought up the point that using uniformResourceIdentifier instead
   of a new otherName would avoid that any part of the ecosystem including 
   diagnostic tools would have to be software updated with new ASN.1
   en/decode work and create unique names useable outside certificates as well.

   If we used "acp:<local>@<acp-domain-name>", this would require
   review process for the new "acp:" scheme, which according to my reading of
   process would take maybe up to one month. Barry suggested to simply
   register an IETF URN parameter (RFC3553), e.g.:

       urn:ietf:params:acp:<local>@<acp-domain-name>

   IANA registry: https://www.iana.org/assignments/params/params.xhtml
       Registration procedure: IETF review (which i guess is the ACP draft IETF review).

So, would love to hear opinions of a) vs. b). Am i overselling the URI option
vs. the otherName option ? I have no experience on this backend side, i am
just trying find the most pragmatic, easy to adopt option for operators,
and i have seen a of backend systems (inventory management or the like)
where names are shuffled around, and we started using email addresses because
those are always supported identifier types in backend systems. No idea if URI are that common,
but at least they could be there because they are an existing defined name/address type.
For otherName, those uses outside certificates would need to come up with their own
field type i think.

Given how this is not an email address anymore, it
would be prudent to introduce one degree of extensibility easier to manage:

      otherName: node:local@acp-domain-name
      URN:       urn:ietf:params:acp:node:<local>@<acp-domain-name>

Where "node" is the value we define in ACP, and other values here
are the extension points.

Final note: of course we loose the ability to use public CA that an
sign rfc822Name, e.g.: via ietf-acme-email-smime, which we would have
if we whee permitted to use email addresses as ACP names, and i was getting
fond of that option, but given how we did not perceive this nice option
when we started ACP, its at least no set-back from the original ACP goals.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Jun 2020 13:25:42 -0400

One minor additional point, otherName would allow binary encoding, which might be helpful for the IoT environment.  The URN approach does require ASCII string.

Russ

> On Jun 30, 2020, at 12:10 PM, Toerless Eckert <[email-masked]> wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 30 Jun 2020 20:59:24 +0200

Hi Toerless,

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.

Eliot

> On 30 Jun 2020, at 18:10, Toerless Eckert <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jun 2020 22:30:18 +0200

On Tue, Jun 30, 2020 at 08:59:24PM +0200, Eliot Lear wrote:
> Hi Toerless,
> 
> 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.

Thanks, Eliot. This was/is my initial thinking. let me see what i can
put into the ntext rev. quickly.

Just learned of one benefit of otherName in that it should also be
possible to signal it in IKEv2 for IDi/IDr via ID_DER_ASN1_GN...

I think ultimately we can define them to be interchangeably, but not quite sure
how yet.

Cheers
    toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jun 2020 21:34:11 -0400

Eliot Lear <[email-masked]> 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).

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 1 Jul 2020 03:59:38 +0200

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:
>     > that the tooling ??? in particular OpenSSL ??? will handle it better.
> 

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Jun 2020 22:25:46 -0400

> still have to write a standard human consumption representation, i

I prefer a string.

    mcr> I would prefer CBOR encoding, if there is consensus that it should not be a string.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Jul 2020 14:43:16 +1200

I do agree that avoiding ASN.1 is a very desirable goal, for exactly
that reason: high probability of human error. So my gut feeling
is to go for a URI.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Jul 2020 00:02:30 -0400

> that reason: high probability of human error. So my gut feeling

otherName can trivially contain a UTF8 string.
yes, there is an OID that goes in first, but it is already implemented.