Toerless: Your example is making my point: [email protected] <mailto:[email protected]>. 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 protected]> wrote: > > Russ, > > ...getting to backlog... > > inline. > > On Fri, Jun 19, 2020 at 12:32:56PM -0400, Russ Housley wrote: >> 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 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 protected] for contractors (temp workers) to > keep the nice [email protected] 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 protected]. > 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 > >>>>>> 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. >>>> >>>> (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.) >>>> >>>>>> 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. >>>> >>>> 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). >>>> >>>>>> 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. >>>> >>>> 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 >>>> >> >> _______________________________________________ >> Anima mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/anima > > -- > --- > [email protected]
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
