Subject: [Anima-bootstrap] Discussion re. encoding of ACP parameters in LDevID

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Jun 2016 16:34:08 -0700

Thanks for starting the discussion about how to encode the parameters
needed for the ACP in the LDevID. Wanted to summarize so folks, especially
those who where not on the weekly call can chime in, and propose one
encoding as well:

So, For the ACP we had agreed a long time ago that we would "somehow"
encode the IPv6 address used by the ACP and the domain-name of the ACP
into the LDevID. The IPv6 address is lifetime stable, aka: an identifier,
so appropriate for the LDevID.

One highly desirable goal of the AN certificate is that it could be used
not only for ACP forming but also for other purposes. Therefore, in an
ideal world the cert parameters used to encode domain-nae and IPv6 address
should be newly defined parameters: This would allow that any other use
of the certificate could freely choose its parameters in the cert and not
be in conflict with the ACP IPv6/domain-name.

During the call Max and MichaelR heavily chimed on a pragmatic approach
where we would not define new parameters, because that could easily break
any pre-existing ASN.1 parser in any code that would see the certificate.

So we ended up discussing which existing parameter would least collide:

'subjectname' and 'ou' parameters are already heavily used so not
good contenders when we want to avoid conflicting data.

MichaelR suggested AltName, which is a list of "names", each one with
a type. IP address and Domain-name are both types. We discussed how those
could be used. 

  - It is very likely that a Domain-Name might already be used for some
    other purpose. Of course it is possible to have multiple Domain-Names,
    but then it wuold be tricky to figure out which of the domain names
    is the one of the ACP (possible, but tricky).
  - An IPv6 address seems to be much less likely to be used, Max was saying some
    systems using certs to authenticate IPsec connections might use them though
    (if i remember correctly)

There are a few other AlName types, but most of them where structured,
eg: similar to subject-name with 'ou' fields or the like.

So: My Favourite is actually the rfc822addr. Aka: An email-address:

     anima.acp+FD99:B02D:8EC3:0:200:0:6400:[email-masked]

Aka: The domain part is simply the domain name for the ACP. The
user-name part is a fixed username value of "anima.acp" followed by +,
followed by the IPv6 ACP address.

Not a new field but existing. Very little used. If it was ever used, it
would most likely be informational, aka: not used in any protocol,
except if it was a user-certificate, which is most likely exactly what an
AN domain-certificate is not.

Encoding is choosen to make it explicitly recognizeable by humans and
machine process, in case there is actually another email address.

Worst case: This address format could even be used as an email address,
and given how the IPv6 address is after the +, it actually is to
most modern email systems just a single user (anima.acp) with just a modifier
part (ipv6 address), so easy to set it up to be routed to one mailbox
if anyone desires to do so.

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Jun 2016 14:20:07 +1200

On 15/06/2016 11:34, Toerless Eckert wrote:

...
> The IPv6 address is lifetime stable

Define lifetime please.

...
>      anima.acp+FD99:B02D:8EC3:0:200:0:6400:[email-masked]

I've got no strong preference here but I want to add a constraint.
It's essential that if we include a literal IP address, it is canonical
so that text comparisons will always succeed. Therefore following RFC 5952
is a MUST (even though that RFC itself is only a SHOULD).

Therefore your example should be

anima.acp+fd99:b02d:8ec3:0:200:0:6400:[email-masked]

(and, btw,
anima.acp+fd99:b02d:8ec3::200:0:6400:[email-masked]
would be incorrect even though it's the same binary address)

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Jun 2016 19:24:41 -0700

> > The IPv6 address is lifetime stable

As long as the cert is valid.

> would be incorrect even though it's the same binary address)

Ack. I continue to copy & paste IPv6 addreses from some random Cisco IOS
CLI, which alas is not RFC 5952 compliant ;-(

Cheers.
    Toerless