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

[Toerless Eckert <[e-mail]>]

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

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

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

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

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

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

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]