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

From: "t.petch" <[email-masked]>
Date: Wed, 5 Oct 2011 14:22:26 +0200

---- Original Message -----
From: "Alan Luchuk" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 30, 2011 8:50 PM
>
> >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.

Alan

This issue came up when the I-D was being reviewed and Jeff said

"I'm not sure what this is supposed to do. It sounds like "pick any
arbitrary SAN you see in the certificate, and turn it into a securityName".
But that leaves unspecified which one to pick if there is more than one,
and how to turn arbitrary otherName types into an SNMP securityName."

which is what we have ended up with.

But the onus is on the generator of the certificate.  The intention is that
fields
such as SAN are an identifier for the party in question and that the certificate
provides a cryptographic binding between key and identifier, with the
protocol, such as TLS, providing proof of possession of the key, so if the
identifier does not identify, then that is a problem with the certificate
issuer.

For example, every organisation that has ever employed me has given me an
employee number and that (or SSN), coupled with an organisation identifier,
would
uniquely identify me in a certificate, which would then identify the netconf
or SNMP client to the server.

Tom Petch

> 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
>