Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

[Alexander Clemm <[e-mail]>]

Hi Kent

More responses, <ALEX>

--- Alex

From: Kent Watsen [mailto:[e-mail]]
Sent: Thursday, February 23, 2017 2:52 PM
To: Alexander Clemm <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

>> - should the leafs not starting with "cert-" start with "sig-", to better match section 6.1?
>
> <ALEX> No, that would actually match less and be misleading.   The parameters mentioned in 6.1.1
> refer to configuration parameters for certificate blocks, and are accordingly prefixed “cert”.  The
> parameters mentioned in 6.1.2 are related to Signature Blocks and are accordingly prefixed with
> “sig” (sigMaxDelay, sigNumberResends, sigREsendDelay, and sigResendCount).  So, you might
> actually want to consider prefixing max-delay, number-resends, resend-delay, and resend-count
> with“sig-“. </ALEX>

Exactly, we agree.   These were the leafs I meant by "not starting with 'cert-' ".

<ALEX>
Ah, okay.  Yes, we agree; I misunderstood your earlier sentence.
</ALEX>

> Syslog-sign does not specify how these types got there and what key material they
> used.  Now, if you wanted to manage that as well, sure, but now you would be getting
> into TLS territory as you mention and I would think this should be kept outside the
> scope.

That Syslog-sign doesn't specify this is a good response as well.  But answer
me honestly, isn't it something that a device would have to have configured
and, if so, wouldn't it make most sense for that configuration to be in this
module?

FWIW, I don't think that it's TLS-territory so much as keystore-territory.

<ALEX>
True, this is keystore territory, and I don’t think this should venture in that direction – the can be considered clearly out of scope.
However, what would actually make sense would be to offer a configuration option that clearly states which of the signature options (and signing material) should be used.    Clearly the ability to configure this will be needed.

If you want to accommodate this, you probably need to consider another modification to the model:  It is conceivable that there could be multiple signers, and different signers might each use a different option.  Therefore, to allow for differentiation by signer, you might want to consider introducing a corresponding parameter under a list of signers.  (You could even move the configuration parameters into this list, although frankly I would opt to keep those parameters global (and the use of the model simple), not per-signer.)
</ALEX>

Thanks,
Kent        // shepherd