Subject: [pkix] AD review of draft-ietf-pkix-cmp-transport-protocols

From: Sean Turner <[email-masked]>
Date: Thu, 02 Feb 2012 18:54:43 -0500

I've reviewed draft-ietf-pkix-cmp-transport-protocols and have the 
following comments I'd like to see addressed prior to IETF LC:

1) s1: r/Certificate Authorities (CAs)/Certification Authorities (CAs)

2) s1: r/an own polling/its own polling

3) s1: remove the following because it sounds like marketing:

   HTTP transport is generally easy to implement, traverses network
   borders utilizing ubiquitous proxies and is already commonly found in
   existing implementations.

4) s3.1/s9: references for RFCs 1945 and 2616 are normative because 
there is 2119 language associated with them in s3.1.  Also:

- I think what you're trying say is that either protocol can be used by 
clients so I think you need to be specific about that and a MUST is 
needed (saying MAY for both seems odd to me).

- But, I've been told that HTTP 1.1 is more widely implemented so can we 
make it the preferred version and then make 1.0 a MAY?

OLD:

   Either HTTP/1.0 as described in [RFC1945] or HTTP/1.1 as in [RFC2616]
   MAY be used.  Server implementations SHOULD be able to interact with
   counterparts utilizing either HTTP protocol version.

NEW:

   Clients and servers MUST support HTTP/1.1 [RFC2616].  Clients and
   server MAY also support HTTP/1.0 [RFC1945].

5) s3.2: Not sure I can parse the following:

   HTTP permits to reuse a connection for subsequent requests.
   Implementations may use this functionality for messages within the
   same transaction but MUST NOT rely on that as e.g. intermediate HTTP
   proxies might terminate the connection after each request/response
   pair.

did you mean to say:

   ... MUST NOT rely on this because intermediate HTTP proxies might
   terminate the connection after each request/response pair.

6) s3.3: Not sure the DER-encoded part is necessary isn't that already 
covered in CMP: ?

   OLD: An ASN.1 DER-encoded PKIMessage

   NEW: A PKIMessage

7) s3.3: I think response is better than reply:

OLD: the server returns the CMP reply

NEW: the server returns the CMP response

8) s3.3: I think you need to be clear that you're talking about the HTTP 
status codes because there are also CMP status codes:

OLD: The response status

NEW: The HTTP response status

9) s3.3: Please be specific about the announcement types:

OLD:

   HTTP responses to pushed CMP Announcement messages
   utilize the status codes 201 and 202 to identify whether the received
   information was processed.

NEW:

   HTTP responses to pushed CMP Announcement messages (i.e.,
   CA Certificate Announcement, Certificate Announcement,
   Revocation Announcement, and CRL Announcement) utilize the
   status codes 201 and 202 to identify whether the received
   information was processed.

10) s3.3: Do you need to say anything about redirection?  Like is it 
allowed or should the client not follow them?  I note there's some text 
in the security considerations but it might be worth also adding in this 
section.

11) s3.4/s9: RFC 2510 is a normative reference because that's where 
application/pkixcmp is defined.  This is going to force a downref 
because RFC 2510 is obsoleted - not a big deal but something I need to 
remember when I do the IETF LC (hint if you don't see it in the LC make 
sure to tell me so I can fix it).

12) s3.6: r/pop/POP

13) s3.6: Are you saying that the request is directed to something like 
POST cmp/0 or POST http://example.com/cmp/0 HTTP/1.1 for initialization 
requests (i.e., the ASN.1 tag indicates the directory)?

14) s3.7: r/No request message for is specified,/No request message is 
specified,

15) s3.7: r/ASN.1 encoded structures/PKIMessage structures

16) s6: Why isn't this part of s5?  Are you trying to say that there's 
no confidential information included in a PKIMessage and if there you 
ought to use HTTPS?

spt

PS Based on these comments I've placed the document in the following 
state: AD Evaluation::Revised ID Needed.

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Feb 2012 01:19:25 +0100 (MET)

>    server MAY also support HTTP/1.0 [RFC1945].

Unless the protocol is vitally dependent on features that exist only
in HTTP/1.1 (which the original text suggests is not the case),
a "MUST support HTTP/1.1" is in clear violation of rfc2119 Section 6

   http://tools.ietf.org/html/rfc2119#section-6

     6. Guidance in the use of these Imperatives

     Imperatives of the type defined in this memo must be used with care
     and sparingly.  In particular, they MUST only be used where it is
     actually required for interoperation or to limit behavior which has
     potential for causing harm (e.g., limiting retransmisssions)  For
*>   example, they must not be used to try to impose a particular method
*>   on implementors where the method is not required for
*>   interoperability.

-Martin

---

From: Sean Turner <[email-masked]>
Date: Fri, 03 Feb 2012 08:42:06 -0500

> *>    on implementors where the method is not required for

I was shooting for less to implement.  Regardless, I think the first 
sentence needs to be explicit about the client requirements so I could 
live with the following:

   Clients MUST support either HTTP/1.0 [RFC1945] or HTTP/1.1 [RFC2616].
   Servers SHOULD support both HTTP versions.

spt

---

From: "Peylo, Martin (NSN - FI/Espoo)" <[email-masked]>
Date: Fri, 10 Feb 2012 15:40:08 +0200

Hi Sean and Martin,

thank you for your excellent review comments.  Please excuse that I
haven't found time during this week to process them but be assured that
this is with high priority in my backlog.

I will implement the needed changes you suggested, do some additional
research where needed, and will come back with detailed replies for each
item asap.

Kind regards,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Sean Turner
Sent: Friday, February 03, 2012 3:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] AD review of draft-ietf-pkix-cmp-transport-protocols

spt
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Peylo, Martin (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 15 Feb 2012 23:18:29 +0200

Hi,

I've just uploaded a new draft 16 implementing most of the great
suggestions 
I got from Sean Turner.  Explicit answers to each issue Sean identified
are below.  There have also been some minor changes to text in close
relation
to those issues - which are mentioned at the relevant issue.

> 1) s1: r/Certificate Authorities (CAs)/Certification Authorities (CAs)
Done.

> 2) s1: r/an own polling/its own polling
Done.

>    existing implementations.
Done.

>    server MAY also support HTTP/1.0 [RFC1945].

Changed the text to Sean's suggestion from the later mail as a reply to 
Martin Rex' intervention:

>    terminate the connection after each request/response pair.

Done - while it sounds the same for me (non-native English speaker) ;-)

>    OLD: An ASN.1 DER-encoded PKIMessage

I couldn't figure out if RFC4210 actually explicitly requires that the
whole PKImessage is DER-encoded.  It mentions that signatures need to be

calculated over the DER-encoding of certain fields.  It is mentioned in
the transport draft as I once encountered someone who thought about
creating an CMP implementation using XML-encoding format.  It is now
changed to "A DER-encoded PKIMessage", removing the redundant "ASN.1".
I hope that is acceptable?

> NEW: the server returns the CMP response
Done.

> NEW: The HTTP response status
Done.

>    information was processed.
Done.
 
> in the security considerations but it might be worth also adding in
this

The following paragraph has been added to s3.3:

While "Redirection 3xx" status codes MAY be supported by
implementations,
clients should only be enabled to automatically follow them after
careful
consideration of possible security implications.

Additionally the following has been extended in the same paragraph to
help
the reader:
2xx -> "Successful 2xx"
4xx -> "Client Error 4xx"
5xx -> "Server Error 5xx"

Also in the security considerations 301 was extended to "301 Moved 
Permanently".

> sure to tell me so I can fix it).
RFC2510 is moved to be a normative reference in s8.1.

> 12) s3.6: r/pop/POP
This was taken directly from RFC4210 but is now anyway removed
completely 
(see 13).

> requests (i.e., the ASN.1 tag indicates the directory)?'

The list of PKIMessages including the Introduction (from "The following 
list ...") is removed completely.  It had been overlooked before that
this
list of Messages which can be used by a client initiating the
interaction
with a server was forgotten to be removed in an earlier version of the 
draft and - now orphaned - only creates confusion.  The initially
intended 
information is in RFC4210 and therefore redundant.

> 14) s3.7: r/No request message for is specified,/No request message is
The whole sentence was changed to:

As no request messages are specified for those announcements they can
only 
be pushed to the recipient.

> 15) s3.7: r/ASN.1 encoded structures/PKIMessage structures
Done.

> no confidential information included in a PKIMessage and if there you
Done, added as list item 4 in s5.

Also the following was changed in security considerations:

To be more general in the introduction as needed:
OLD: "... need to be considered by server side implementers" 
NEW: "... need to be considered by implementers and users"
--> added "... to an HTTP server" in list item 1. to clarify *where* the
    resources might be exhausted.

In list item 2.: "(unless tunneled via TLS)" was removed as mentioning
this doesn't seem to add any real value.

> state: AD Evaluation::Revised ID Needed.

Thank you Sean, your comments are more than valuable!  Please feel free
to
keep the document in this state as long as you can spot anything you'd 
like to see improved!

Kind regards,
Martin