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

[Lishan Li <[e-mail]>]

2016-11-12 1:33 GMT+08:00 神明達哉 <[e-mail]>:

> At Thu, 10 Nov 2016 00:48:53 +0800,
> Lishan Li <[e-mail]> wrote:
>
> > > 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.
>
> There are THREE types of certificates:
> - one type is used only for encryption, which contains the public key
>   for the encryption algorithm
> - another is used only for authentication, which contains the public
>   key for the signature algorithm
> - yet another is used both for encryption and authentication, which
>   contains the public key for the encryption and signature algorithms.
>
> So...
>
> > 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.
>
> ...if this is a proposal of adding a new field to the certificate
> option, yes, I think that's one way forward except that there are
> three types.
>
> Alternatively, we might add both an EA-id and SA-id fields to the
> option:
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |      OPTION_CERTIFICATE       |         option-len            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            EA-id              |            SA-id              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    .                  Certificate List(variable length)            .
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> (I'm not sure if this has to be a list of certificates instead of one
> certificate, but that's a different question).


> And we can use a value of 0 for EA-id and SA-id to mean this
> certificate is not supposed to be used for encryption and signature,
> respectively.  (The combination of 0, 0 makes no sense so we should
> probably prohibit the use of it explicitly).
>
[LS]: So, there is no need to define a new field. The EA-id and SA-id are
used to identify the certificate type.
And the certificate list field should be changed to certificate field. If
multiple
certificates are contained, then multiple certificate option is contained.

Best Regards,
Lishan