Subject: Re: [Netconf] Updating NETCONF over TLS document (RFC5539)

From: Alan Luchuk <[email-masked]>
Date: Fri, 30 Sep 2011 14:50:38 -0400 (EDT)

Hello,

>I think this is what we do need.
>How  does RFC 6353 deal when certificates include multiple instances of the
>subjectAltName (refer to Wes example, multiple rfc822Names)?

RFC 6353 has a defined mechanism for handling different fields of the
subjectAltName extension (e.g.; rfc822Name, dNSName, iPAddress), but I
think it is silent about handling multiple instances of the same field
(e.g.; multiple instances of the rfc822Name).  I've taken a quick scan
over RFC 6353 again, and do not immediately notice anything about multiple
instances of the same field.  I'd have to re-read carefully to make sure.

In the case where a certificate contains multiple instances of the same
subjectAltName field, it would be easier for our implementation if a 
single NETCONF username was produced from a certificate.  That is, the
mapping code prioritizes and selects the NETCONF username, rather than
producing a set of NETCONF usernames that are handed up and must be 
prioritized by a higher layer in the code.  I would suspect this would 
be true for other NETCONF/TLS implementations as well.

Perhaps you have posted this already, but do you have a suggested mechanism
for handling multiple instances of the same field in the subjectAltName
extension?  If so, I would envision this as just another mapping choice,
with perhaps another mapping configuration parameter.

Regards,
--Alan

 ------------------------------------------------------------------------------
 Alan Luchuk               SNMP Research, Inc.          Voice:  +1 865 573 1434
 Senior Software Engineer  3001 Kimberlin Heights Road  FAX:    +1 865 573 9197
 [email-masked]           Knoxville, TN  37920-9716    http://www.snmp.com/
 ------------------------------------------------------------------------------

---

From: Badra <[email-masked]>
Date: Fri, 30 Sep 2011 21:05:53 +0200

> with perhaps another mapping configuration parameter.

Well, a priority order should help here, and as Wes pointed out, first hit
wins
Best regards
Badra