[Servercert-wg] Correct state and locality for US army post offices

[Ryan Sleevi]

On Fri, Jun 19, 2020 at 10:31 AM Tim Hollebeek via Servercert-wg <
servercert-wg at cabforum.org> wrote:

>
>
> A quick question for you all, since the baseline requirements are unclear
> here.
>
>
>
> For those unfamiliar with addresses for US foreign military bases and
> diplomatic posts, they look something like this:
>
>
>
> Somepersonplaceorthing XXX
>
> Miltary unit / box / whatever
>
> APO AE 12345
>
>
>
> See also: https://faq.usps.com/s/article/How-Do-I-Address-Military-Mail
>
>
>
> These locations intentionally do not use foreign city / state codes to
> avoid having their mail routed through foreign mail
>
> systems, and in some cases because the location is US soil and/or not
> subject to foreign jurisdiction anyway.  These locations
>
> even have US zipcodes assigned.  For example, 962xx is actually in Korea,
> and is associated with the two letter postal
>
> code AP.  For example, the US embassy in Seoul has the following US
> mailing address:
>
>
>
> US Embassy Seoul
>
> Unit #9600
>
> DPO AP 96209
>
>
>
> The question is what is the best practice for converting such an address
> to C=, L=, ST= format.  Options include:
>
>
>
>    1. C=US, L=APO AP, ST=(none)    [ST can be omitted if L is present]
>    2. C=US, L=APO, ST=AP                 [using official postal code as
>    ST]
>    3. other?
>
>
>
> I think it’s pretty clear that (1) complies with the BRs.  The question is
> whether (2) does.  The ST field is defined as
>
> “state or province information”, but we know from previous discussions
> that it is not strictly limited to things named
>
> “states” or “provinces”, as it can also include functionally similar
> political subdivisions like Swiss cantons.  The question
>
> is whether having a US postal code and official two letter postal
> abbreviation means that AP, AE, and AA are legal
>
> values of the ST field.
>
>
>
> Of course, this question would be easy to answer if my suggestion to use
> ISO 3166-2 as the official list of valid ST fields
>
> had been adopted, but unfortunately there didn’t seem to be much support
> for it.
>

Specifically, the adoption of ISO 3166-2 would have prohibited ST=AP
because AP is not a recognized division within ISO 3166-2 for US, correct?

And this is specifically in the context of whether the verification of
address in 3.2.2.1 uses postal routing as the determinant for address of
existence, right?

Here's a different way of thinking about this example: Would there be any
concern if, for example, a Subscriber applied for an OV certificate, and
the Subscriber provided a "utility bill, bank statement, credit card
statement, government-issued tax document, or other form of identification
that the CA determines to be reliable", with that information going to a
mail forwarding service / virtual mailbox?

Obviously, this would be a massively different level of assurance than "A
site visit by the CA or a third party who is acting as an agent for the
CA;", but both scenarios are permitted by 3.2.2.1.

If a CA has issues with Subscribers using such "dead drops", then it would
seem they should have similar trouble with respect to the above example.
Alternatively, if there's no trouble with the above example, then there
should be no trouble with the use of such routing services.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200619/218841a1/attachment-0001.html>