Re: [Anima] rfc822Name use in Autonomic Control Plane document

Toerless:

Your example is making my point: noreply@bad-corporation.com <mailto:noreply@bad-corporation.com>.  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 <tte@cs.fau.de> 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 temp.john.doe@example.com for contractors (temp workers) to
> keep the nice john.doe@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 noreply@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
> 
> -- 
> ---
> tte@cs.fau.de