Re: [Dime] [DIME] Comments about AVP for crypto key transport draft

[Sebastien Decugis <sdecugis at nict.go.jp>]

Hello Qin,

In general I agree that a grouped AVP is best suited to transport a Key
and its related information: name, lifetime, other (depending on the keys).

However, for the efficiency of parsing the message, I personally think
that having the key "type" *inside* the grouped AVP is not efficient,
since it means that the implementation has to parse the message "in
depth" to find the key it is interested in. If we define different
grouped AVPs for different key types, we have a better parsing
efficiency, and save some space in the message (key type AVP is not
needed). In addition, this approach allows to have a different ABNF for
each key type (for example, making the Key Name mandatory for DSRK keys,
but not for rMSK keys). This is the approach I followed in the draft
draft-sdecugis-dime-diameter-erp-01, which I plan to reproduce in the
upcoming draft-ietf-dime-erp-01.

About the transport of the MSK / rMSK, I am not sure if people will be
interested in changing the existing commands to use this more generic
approach of grouped AVPs. It is probably not a sufficient reason to
update the commands definitions (such as DEA for example), even though
the current format is quite strange :-D

Anyway, once we agree on the format of the suitable AVP to transport the
keys (in the case of ERP: DSRK, rMSK), I have no strong opinion as if it
is better to have it defined inside the Diameter ERP document or in a
separate document, as you know.

Best regards,
Sebastien.

> In the Diameter ERP document, the AVP of ERP keys are also defined.
> However these transport of ERP keys are specific to the ERP
> application and can not solve how to transport more than one
> cryptographic keys in one message.
>

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)