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

[Lishan Li <[e-mail]>]

2016-11-09 1:18 GMT+08:00 神明達哉 <[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.
>
[LS]: There are two types of certificate: one type is used for encryption
and authentication, which contains the public key for encryption algorithm;
another type is used for signature versification, which contains the public
key for signature algorithm. We can set one field for this. If the field is
zero, then it indicates the first type. If the field is 1, then it
indicates the
second type. Looking forward to your further guidance.

Best Regards,
Lishan