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

[Tim Hollebeek]

I’m a little bit surprised to see no other opinions here.

 

Yes, you followed my logic correctly: adoption of ISO 3166-2 for the ST= field would make the answer to this question unambiguous (in the negative; i.e. AP is prohibited).

 

In the absence of such a clear standard, we must look elsewhere.  I don’t think the comment about “dead drops” is helpful, and seems to be trying to make a false equivalence.  As I noted in my background, these addresses exist to increase the level of assurance for mail delivery to these addresses, which is kind of the opposite.

 

I still think that going forward, ISO 3166-2 is the best right answer for a clear, bright line about what belongs in the ST= field, but this one was brought up internally as an interesting case, since the United States has formalized these codes at the same level as the postal codes for US states, and they cover areas that are US territory but are 

not covered by an ISO 3166-2 code.  I thought it was an interesting point, and wanted to hear what others thought.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Friday, June 19, 2020 10:51 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Correct state and locality for US army post offices

 

 

 

On Fri, Jun 19, 2020 at 10:31 AM Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org <mailto: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/20200630/94a2b59a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200630/94a2b59a/attachment-0001.p7s>