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

[Eliot Lear <[e-mail]>]

> On 24 Jun 2020, at 11:39, Toerless Eckert <[e-mail]> wrote:
> 
> 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. [e-mail] - 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

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.

> 
>> That is- someone may be able to nab an email address via the mail subsystem a la [e-mail] <mailto:[e-mail]>,
> 
> 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.

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

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

Ok, but...


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

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?


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

I like that idea.


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

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

Eliot
> 
> 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
> 
>> Eliot
> 
> 
> 
>> _______________________________________________
>> Anima mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima
> 
> 
> -- 
> ---
> [e-mail]