Last Call Review of draft-housley-ct-keypackage-receipt-n-error-05
review-housley-ct-keypackage-receipt-n-error-05-secdir-lc-perlman-2013-11-14-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.



This document defines a syntax for two Cryptographic Message Syntax (CMS)
content types that can be used in responses to messages containing key
packages. One is for acknowledging receipt and the other is for reporting
errors. The exact syntax is unimportant to security and the message purpose
seems sensible and non-controversial.



A few thoughts (mostly on procedural rather than technical issues):



In addition to defining the key-package-receipt and key-package-error content
types, this document defines a KeyPkgIdentifierAndReceiptReq attribute. It
wasn’t clear (at least to me) whether this document was also defining this
attribute or whether this information was included in this document for the
purpose of providing context.



The document defines a long list of error codes with the comment “Expect
additional error codes” without specifying a mechanism for additional error
codes to be defined. It also says that there are no IANA considerations, but I
would assume that IANA would operate the registry for things like the error
codes listed here. If not IANA, where would the definitive registry be?



The KeyPkgReceiptReq includes a specification as to where to send the receipts,
and that specification is a sequence of distinguished names. There is no
specified limit on the number of distinguished names and no stated requirement
that the names have any relation to the sender of the Key Package. This
potentially represents a denial of service amplification engine.



There is no indication that the key package identifier be unguessable or tied
cryptographically to the key package contents. As a result, there is the
potential that an attacker could stop delivery of a key package and send his
own substitute key package with the same identifier. This would result in the
recipient acknowledging a key package that he did not in fact receive. This
could potentially confuse the sender about the state of the exchange.



minor typo? The last line of page 5 says “which receivers of the key package
are expected to return receipts”. I believe that should read “which receivers
of the key package are requested to return receipts”.

Radia