Certificate Management over CMS (CMC) Updates
draft-ietf-pkix-rfc5272-bis-08

[Ballot discuss] Lionel Morand raised a few issues related to backwords compatibility of some of the changes specified in this document. I would like to ...

[Ballot discuss]
Lionel Morand raised a few issues related to backwords compatibility of some of the changes specified in this document. I would like to hear the answers of the document authors and make sure that these aspects were taking into consideration.

1. Update to RFC 5272:
- In the section 2.3. (Replace Section 6.3. Linking Identity and POP Information):

Three mechanisms are defined for linking identity and POP information: witness value, certificate linking and shared-secret/name matching. In this document, the first two mechanisms MUST be supported by clients and Servers whereas only the Witness value based mechanism was mandatory to support and the certificate based linking was not defined in RFC 5272. This might cause backward compatibility issues with legacy implementation and some text may be required to indicate how to deal with legacy clients/servers.

2. Update to RFC 5272:

- In section 2.6. New Section 6.21 Response Body Control

  "The Response Body Control is designed to enable an RA to inform an EE
  that there is an embedded response message that MUST be processed as
  part of the processing of this message."

This a new feature compared to RFC 5272. Does the RA need to know that EE supports this feature before using it? Or is it assumed that the whole system support the same version of the RFC? Maybe some text would be required here also.

3. Updates to RFC 5273
- In section 3.1. Update to Section 5 TCP-Based Protocol:

A new IANA-registered Port Number is required whereas it was previously possible to use any port number in RFC 5273. Does it mean that any legacy implementation will have to be upgraded to support this new registered Port Number?

[Ballot comment] I have not done a detailed review of this document and will trust that the Security ADs have done. I am somewhat puzzled ...

[Ballot comment]
I have not done a detailed review of this document and will trust that the Security ADs have done.

I am somewhat puzzled by...
  This document contains a new IANA considerations section to be added
  to [RFC5273] as part of this update.

Section 3.2 says...
  Reference: [ RFC-to-be ]
...and I assume that means *this* document.

So the new IANA section is as a result of 5273, but not part of it.

IANA has questions about the IANA Action in this document. IANA understands that, upon approval of this document, there is a single IANA action which ...

IANA has questions about the IANA Action in this document.

IANA understands that, upon approval of this document, there is a single
IANA action which must be completed.

In the Service Name and Transport Protocol Port Number Registry a new
port number will be registered as follows:

Service name: pkix-cmc
Port Number: [ TBD ]
Transport protocol: TCP
Description: PKIX Certificate Management using CMS (CMC)
Reference: [ RFC-to-be ]

IANA Question -> who should be listed as the assignee and contact for
this port? Please see:

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

IANA understands that this is the only IANA Action required upon
approval of this document.

(1.a) Stephen Kent is the document shepherd for the document. He has reviewed the previous version of the document (the latest version addressed nit ...

(1.a) Stephen Kent is the document shepherd for the document. He has
reviewed the previous version of the document (the latest version
addressed nit problems) and believes that the document is ready for
advancement (despite a few, minor typos).

(1.b) The document has had sufficient review both internally and externally.

(1.c) I have been told that document has been reviewed for ASN.1
compliance (by the author) and has been checked using the OSS syntax
checker using dummy values. These dummy values will need to be replaced
before publication.

(1.d) There are no specific issues or concerns that the document presents.

(1.e) This document represents a strong consensus of a small number of
experienced individuals in the PKIX WG. No dissension was voiced on the
PKIX list.

(1.f) There has been no dissension on this document.

(1.g) A new version has been published to address all outstanding nits.

(1.h) The document has split references into normative and
informational. All of the normative references are documents that are
currently on the standards track.

(1.i) The IANA section exists and states no work is needed by IANA.

(1.j) The ASN.1 will be OK when the TBD values in the module are
replaced with real values.

(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up? Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
This document represents a set of needed changes to the base Certificate
Management over CMS (CMC) document. These changes are motivated by
problems that were identified either in the process of developing
implementations or to support additional features that have been
requested by authors of other documents (e.g., support for the Suite B
profile of CMC).

Working Group Summary
There were no significant issues about the document that were raised
during the WG process, as such the changes represent the consensus of
the active participants on the document

Document Quality
The only current known implementation is a partial one by the document
author, however much of the work is being done at the request of people
writing other documents and as such it is expected that they will be
either providing or requesting implementations of these features.