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

[Lishan Li <[e-mail]>]

2016-11-14 15:42 GMT+08:00 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.
>
[LS]: In this way, the certificate option and Signature option all contain
the SA-id field. And the content of the two SA-ids are same.

>
>