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 temp.john....@example.com for contractors (temp workers) to
keep the nice john....@example.com 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 nore...@bad-corporation.com.
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
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
