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 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. Closed

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]
1. I believe that this format of defining in one RFC updates for other 3 RFCs is quite difficult to read and follow.

2. - In section 2.5. New Section 6.20 RA Identity Proof Witness control:

"Identity Proof Version 2" should be "Identity Proof Version 2 control" if I'm correct.

[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]
Doesn't the new change subject name thing require a new security
consideration? E.g. if an RA says it'd like a new cert renaming
stephen.farrell to *.google.com?  I think just a sentence saying
that the RA and CA need to ensure that both the new and old names
adhere to any relevant policies/practices would do fine.

There may be a case for also making the general point as well
that CAs MUST check names are according to policy/practice
as well, but even if so, the new name change thing should
also get a mention I reckon.

But that can all be done in one sentence so it should be easy.

[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.

[Ballot comment]
I don't have any problem with this if the WG and people implementing from it are happy with it, but it does seem that the format as just a collection of the changes rather than a stand-alone document to be possibly confusing and error-prone to work from.  However, if the real stakeholders are happy with it, then that's all that matters, I guess.

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.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Certificate Management over CMS (CMC) Updates) to Proposed Standard


The IESG has received a request from the Public-Key Infrastructure
(X.509) WG (pkix) to consider the following document:
- 'Certificate Management over CMS (CMC) Updates'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-08-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document contains a set of updates to the base syntax for CMC, a
  Certificate Management protocol using the Cryptographic Message
  Syntax (CMS).  This document updates RFC 5272, RFC 5273 and RFC 5274.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5272-bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5272-bis/


No IPR declarations have been submitted directly on this I-D.

(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.