Subject: [Spasm] review of of draft-ietf-lamps-eai-addresses-00

From: Sean Turner <[email-masked]>
Date: Thu, 27 Oct 2016 01:02:03 -0400

These are pretty nitty:

0) I gotta ask whether this document should include an “Updates: 5280 (once approved)” header?

1) I guess s2 should be updated to also refer to ASN.1 for the formal syntax used in s3 as well as the ASN.1 module (as suggested by Russ); also requires adding a normative reference to ASN.1?

2) I’m not sure about this one, but do you need to say anything about wildcards?  The last para in s4.2.1.6 before the ASN.1 in 5280 says it’s up to the application, but maybe that’s already covered somewhere else? 

3) s7: (I suspect after Russ’ comment you knew this) if you put in an ASN.1 module you’ll also need to register an OID for the module and the extension.  Something along these lines ought to work for that section:

   This document makes use of object identifiers for the
   other name defined in Section 2 and the ASN.1 module
   identifier defined in Section [insert location]. IANA is kindly
   requested to make the following assignments for:

  o  The [insert name of module] ASN.1 module in the SMI
      Security for PKIX Module Identifier registry:
      http://www.iana.org/assignments/smi-numbers/smi-
      numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0

  o  The smtputf8Name other name in the PKIX Other
      Name Forms registry:
      http://www.iana.org/assignments/smi-numbers/
      smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8

4) Is it worth pointing out that this OTHER-NAME is *not* applicable to IssuerAltName?  The draft is very clear it’s just talking about SubjectAltName but it’s the same syntax and sometimes smart implementers do weird things.  (definitely willing to not have this incorporated, but I thought I should at least bring it up)

spt

---

From: Jim Schaad <[email-masked]>
Date: Thu, 27 Oct 2016 10:58:03 -0700

> -----Original Message-----
> From: Spasm [mailto:[email-masked]] On Behalf Of Sean Turner
> Sent: Wednesday, October 26, 2016 10:02 PM
> To: SPASM <[email-masked]>
> Subject: [Spasm] review of of draft-ietf-lamps-eai-addresses-00
> 
> These are pretty nitty:
> 

Personal opinion - no

> 
> 1) I guess s2 should be updated to also refer to ASN.1 for the formal syntax used
> in s3 as well as the ASN.1 module (as suggested by Russ); also requires adding a
> normative reference to ASN.1?
> 
> 2) I’m not sure about this one, but do you need to say anything about wildcards?
> The last para in s4.2.1.6 before the ASN.1 in 5280 says it’s up to the application,
> but maybe that’s already covered somewhere else?
> 
> 3) s7: (I suspect after Russ’ comment you knew this) if you put in an ASN.1
> module you’ll also need to register an OID for the module and the extension.
> Something along these lines ought to work for that section:
> 
> 4) Is it worth pointing out that this OTHER-NAME is *not* applicable to
> IssuerAltName?  The draft is very clear it’s just talking about SubjectAltName but
> it’s the same syntax and sometimes smart implementers do weird things.
> (definitely willing to not have this incorporated, but I thought I should at least
> bring it up)

I would disagree, while I can't think of a good reason for putting in an IssuerAltName, there is no reason why it cannot be put there.

Jim

> 
> spt
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Sean Turner <[email-masked]>
Date: Thu, 27 Oct 2016 17:10:54 -0400

>> 0) I gotta ask whether this document should include an “Updates: 5280 (once

I could go either way, which probably means NOT doing it is the right thing.

> I would disagree, while I can't think of a good reason for putting in an IssuerAltName, there is no reason why it cannot be put there.

Likewise here, I could see going either way.  If we did preclude it and later somebody came up with a reason to use it you’d we’d have to update to unpreclude it.  That sounds painful so maybe saying nothing is the right thing here.

spt

---

From: Wei Chuang <[email-masked]>
Date: Thu, 27 Oct 2016 17:14:01 -0700

On Thu, Oct 27, 2016 at 2:10 PM, Sean Turner <[email-masked]> wrote:

> >> 0) I gotta ask whether this document should include an “Updates: 5280
> (once
> >> approved)” header?
> >
> > Personal opinion - no
>

I think we would prefer not to allow wildcard in this specification.
Multiple subjectAltName can used instead, and explicit naming is
preferable.  Also wildcards also adds complexity to the matching rules.

> > I would disagree, while I can't think of a good reason for putting in an
> IssuerAltName, there is no reason why it cannot be put there.
>
> Likewise here, I could see going either way.  If we did preclude it and
> later somebody came up with a reason to use it you’d we’d have to update to
> unpreclude it.  That sounds painful so maybe saying nothing is the right
> thing here.
>

Indeed that was the notion for not saying something explicitly since it
wasn't clear there was a use for smptutf8Name in IssuerAltName.  Could go
either way or keep it as is.  Is there a strong preference for it?

-Wei

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 28 Oct 2016 10:10:49 +0100

> On 28 Oct 2016, at 01:14, Wei Chuang <[email-masked]> wrote:
> 
 (Snip)

> Indeed that was the notion for not saying something explicitly since it wasn't clear there was a use for smptutf8Name in IssuerAltName.  Could go either way or keep it as is.  Is there a strong preference for it?

I would rather explicitly allow it. If something is omitted, people will draw different conclusions.

---

From: Sean Turner <[email-masked]>
Date: Fri, 28 Oct 2016 09:06:11 -0400

On Oct 27, 2016, at 20:14, Wei Chuang <[email-masked]> wrote:
> I think we would prefer not to allow wildcard in this specification.  Multiple subjectAltName can used instead, and explicit naming is preferable.  Also wildcards also adds complexity to the matching rules.

I agree explicit naming so I guess a sentence to say that makes sense to me.

> Indeed that was the notion for not saying something explicitly since it wasn't clear there was a use for smptutf8Name in IssuerAltName.  Could go either way or keep it as is.  Is there a strong pre…

I guess I’m leaning towards what Alexey’s train of thought that we should explicit allow it.