Re: [dhcwg] preliminary comments on draft-ietf-dhc-sedhcpv6-17

[神明達哉 <[e-mail]>]

At Tue, 8 Nov 2016 22:02:21 +0800,
Lishan Li <[e-mail]> wrote:

> > (Obviously) the former, but I guess your real question is how the
> > client can determine that.  If so, that's a good point...I wasn't
> > aware of the ambiguity at the time of my previous message.  I'm afraid
> > we need some more additional protocol stuff to resolve this, e.g., add
> > a new field for the certificate option to specify for which it's
> > supposed to be used: encryption, authentication, or both.
>
> [LS]: Another problem is that: whether all the certificates needed to be
> verified for authentication? In general, if the certificate is verified and
> then the public key can be used for encryption.
> So I think one certificate is enough for authentication and encryption,
> which is usually certificate for the public key for E1. There is no need
> to contain the certificate for the public key for signature algorithm.

It'll be possible (and probably quite common) to share the same
certificate (public key) for both encryption and signature.  For
example, if we use RSA for encryption and RSASSA, it's quite likely
that we can use the same public key.  But, unless we impose an
explicit relationship between these two algorithms as part of the
protocol specification we cannot always assume that, so the protocol
itself should be generic so that it will work even if encryption and
signature algorithms are totally independent.  That's why I stated the
above example: "add a new field for the certificate option to specify
for which it's supposed to be used: encryption, authentication, or
both."

Whether to impose such an "explicit relationship" is a different
question, btw.  I think that's certainly an option and can make the
spec simpler at the cost of making it less flexible, but that should
be discussed and described in the spec explicitly, instead of leaving
it as an implicit assumption.

--
JINMEI, Tatuya