Subject: [certid] open issues

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Apr 2010 15:38:38 -0600

I'd like to come up with a complete list of the open issues related to
draft-saintandre-tls-server-id-check. Please reply to this thread with
additional open issues, then I will start a separate thread about each.

Here's what I have so far:

1. Why exclude iPAddress from the scope?

2. Why exclude self-signed certs from the scope?

3. Should we forbid wildcards altogether?

4. Should we provide more guidance regarding wildcards? (For example,
encourage issuance only for Class 2 certs.)

5. We need to document the security considerations for wildcards.

6. Should we move the text about CNs to a non-normative note?

7. Should we remove the rule about allowing a domain name in the CN only
as the leftmost RDN?

8. We need to document the security considerations for CNs.

9. We need to specify how to handle internationalized domain names. (For
example, specify IDNA2003 or IDNA2008 or straight punycode or some
combination of recommendations.)

10. We need to specify matching rules for the uniformResourceIdentifier SAN.

11. We need to specify matching rules for the SRVName SAN.

12. We need to separate the domain checking rules from the service type
checking rules.

Anything else?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 09 Apr 2010 13:26:40 +0100

Hi Peter,

>Here's what I have so far:
This is a good list, thanks.

 [snip]

>Anything else?
I think 2 other more genetic comments were raised:

13. The document need to be clearer on applicability of different SANs 
and on the order they should be checked.
14. The document should be clearer on its scope (e.g. guidelines for 
future protocols versa documenting existing practices).

---

From: Bruno Harbulot <[email-masked]>
Date: Fri, 09 Apr 2010 13:39:23 +0100

Hi Peter,

On 08/04/2010 22:38, Peter Saint-Andre wrote:
> [...]

I would suggest adding a couple of points:

- Use of 'MUST NOT' and ambiguity of 'represent', as I mentioned in:
   http://www.ietf.org/mail-archive/web/certid/current/msg00010.html

- Left-most/right-most should probably be replaced by ASN.1 ordering, 
since left/right ordering depends on the tools. (See Nelson Bolyard's 
e-mail.)

Best wishes,

Bruno.