Subject: [appsdir] Request for review: draft-ietf-pkix-est-03

From: SM <[email-masked]>
Date: Fri, 09 Nov 2012 11:17:19 -0800

Hi Julian, Mark,

There was a request from a Sec AD for an early review 
draft-ietf-pkix-est-03.  Could one of you please review the 
draft?  Let me know which one of you can do it.  I'll set the 
deadline for 19 November.

Sean mentioned s3.2 of the draft, which is titled HTTP Layer Design 
and other sections that also address HTTP response codes.

Best regards,
-sm

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Nov 2012 20:19:29 +0100

On 2012-11-09 20:17, SM wrote:
> draft-ietf-pkix-est-03.  Could one of you please review the draft?  Let
> me know which one of you can do it.  I'll set the deadline for 19 November.
>
> Sean mentioned s3.2 of the draft, which is titled HTTP Layer Design and
> other sections that also address HTTP response codes.
>
> Best regards,
> -sm

Sorry, no bandwidth left right now.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 11 Nov 2012 18:18:00 +0100

> other sections that also address HTTP response codes.

I can't do a complete review, but here's some editorial feedback on the 
HTTP related bits:

> 3.2. HTTP Layer Design
>
>
>    HTTP is used to transfer EST messages.  URIs are provisioned for
>    handling each media type (i.e., message type) as described in
>    Section 3.2.2.  HTTP is also used for client authentication services
>    when TLS client authentication is not available due to lack of a
>    client certificate suitable for use by TLS, as detailed in Section
>    Section 3.2.3.  Registered media types are used to convey EST
>    messages as specified in Figure 5.
>
>    HTTP 1.1 [RFC2616] and above support persistent connections.  As
>    given in Section 8.1 of that RFC persistent connections may be used
>    to reduce network and processing load associated with multiple HTTP
>    requests.  EST does not require or preclude persistent HTTP
>    connections and their use is out of scope of this specification.

I think the paragraph above isn't needed here.

> 3.2.1. HTTP headers for control

s/header/header fields/ (throughout)

>    This document profiles the HTTP content-type header (as defined in
>    [RFC2046], but see Figure 5 for specific values) to indicate the

The HTTP Content-Type header field is defined in RFC 2616, Section 14.17.

>    media type for EST messages and to specify control messages for EST.
>    The HTTP Status value is used to communicate success or failure of
>    EST functions Support for the HTTP authentication methods is
>    available for a client that does not have a certificate.
>
>    CMC uses the same messages for certificate renewal and certificate
>    rekey.  This specification defines the renewal and rekey behavior of
>    both the client and server.  It does so by using the HTTP control
>    mechanisms employed by the client and server as opposed to using CMC.
>
>    Various media types as indicated in the HTTP content-type header are
>    used to transfer EST messages.  Media types used by EST are specified
>    in Section 3.2.4.
>
> 3.2.2. HTTP URIs for control
>
>
>    This profile supports six operations indicated by specific URIs:
>
>    Operations and their corresponding URIs:
>    +------------------------+-----------------+-------------------+
>    | Operation              |Operation Path   | Details           |
>    +========================+=================+===================+
>    | Distribution of CA     | /CACerts        | Section 4.3       |
>    | certificates (MUST)    |                 |                   |
>    +------------------------+-----------------+-------------------+
>    | Enrollment of new      | /simpleEnroll   | Section 4.4       |
>    | clients (MUST)         |                 |                   |
>    +------------------------+-----------------+-------------------+
>    | Re-Enrollment of       | /simpleReEnroll | Section 4.4.1     |
>    | existing clients (MUST)|                 |                   |
>    +------------------------+-----------------+-------------------+
>    | Full CMC (OPTIONAL)    | /fullCMC        | Section 4.5       |
>    +------------------------+-----------------+-------------------+
>    | Server-side Key        | /serverKeyGen   | Section 4.6       |
>    | Generation (OPTIONAL)  |                 |                   |
>    +------------------------+-----------------+-------------------+
>    | Request CSR attributes | /CSRAttrs       | Section 4.7       |
>    | (OPTIONAL)             |                 |                   |
>    +------------------------+-----------------+-------------------+
>
>                                  Figure 4
>
>    An HTTP base path common for all of an EST server's requests is
>    defined in the form of an path-absolute ([RFC3986], section 3.3).
>    The operation path (Figure 4 is appended to the base path to form the
>    URI used with HTTP GET or POST to perform the desired EST operation.
>
>    An example:
>
>    With a base path of "/arbitrary/path" and an operation path of
>    "/CACerts", the EST client would combine them to form an absolute
>    path of "/arbitrary/path/CACerts".  Thus, to retrieve the CA's
>    certificates, the EST client would use the following HTTP request:
>
>    GET /arbitrary/path/CACerts HTTP/1.1
>
>    Likewise, to request a new certificate in this example scheme, the
>    EST client would use the following request:
>
>    POST /arbitrary/path/simpleEnroll HTTP/1.1
>
>    The mechanisms by which the EST server interacts with an HTTPS server
>    to handle GET and POST operations at these URIs is outside the scope
>    of this document.  The use of distinct operation paths simplifies
>    implementation for servers that do not perform client authentication
>    when distributing /CACerts responses.
>
>    EST clients are provided with the base path URI of the EST server.
>    Potential methods of distributing the URI are discussed within the
>    Security Considerations (see Section 6 and Section 4.1).
>
>    An EST server MAY provide additional, services using other URIs.
>
>    An EST server MAY use multiple base paths in order to provide service
>    for multiple CAs.  Each CA would use a distinct base path, but
>    operations are otherwise the same as specified for an EST server
>    operating on behalf of only one CA.
>
> 3.2.3. HTTP-Based Client Authentication
>
>
>    An EST server that has authenticated itself to the client MAY request
>    HTTP-based client authentication.  This request can be in addition to
>    successful TLS client authentication (Section 3.3.1.2) if EST server
>    policy requires additional authentication (for example the EST server
>    wishes to confirm the EST client "knows" a password in addition to
>    "having" an existing client certificate).  Or HTTP-based client
>    authentication can be an EST server policy specified fallback in
>    situations where the EST client did not successfully complete the TLS
>    client authentication (for example if the EST client is enrolling for
>    the first time or the existing EST client certificates can not be
>    used for TLS client authentication).
>
>    HTTP Basic and Digest authentication MUST only be performed over TLS
>    1.1 [RFC4346] (or later).  As specified in CMC: Transport Protocols
>    [RFC5273] the server "MUST NOT assume client support for any type of
>    HTTP authentication such as cookies, Basic authentication, or Digest
>    authentication".  Clients intended for deployments where password
>    authentication is advantageous SHOULD support the Basic and Digest
>    authentication mechanism.  Servers MAY provide configuration

...be careful with BCP14 keywords where they are not needed...

>    mechanisms for administrators to enable Basic and Digest
>    authentication methods.
>
>    Servers that wish to use Basic and Digest authentication reject the
>    HTTP request using the HTTP defined WWW-Authenticate response-header
>    ([RFC2616], Section 14.47).  At that point the client SHOULD repeat

No, by the 401 status code.

>    the request, including the appropriate Authorization Request Header
>    ([RFC2617], Section 3.2.2) if the client is capable of using the
>    Basic or Digest authentication.  If the client is not capable then
>    the client MUST terminate the connection.
>
>    Clients MAY set the username to the empty string ("") if they wish to
>    present a "one-time password" or "PIN" that is not associated with a
>    username.
>
>    Support for HTTP-based client authentication has security
>    ramifications as discussed in Section 6.  The client MUST NOT respond
>    to the server's HTTP authentication request unless the client has
>    authenticated the EST server (as per Section 4.1).
>
> 3.2.4. Message types
>
>
>    This document uses existing media types for the messages as specified
>    by [RFC2585], [RFC5967], and CMC [RFC5272].  To support distribution
>    of multiple certificates for the CA certificate chain, the [RFC2046]
>    multipart/mixed media type is used.
>
>    The message type is specified in the HTTP Content-Type header with a
>    media type.  The use herein is consistent with [RFC5273].
>
>    For reference the messages and their corresponding media types are:
>
>    +--------------------+--------------------------+-------------------+
>    | Message type       |Request media type        | Request section   |
>    |                    |Response media type       | Response section  |
>    |                    |Source(s) of types        |                   |
>    +====================+==========================+===================+
>    | CA certificate     | N/A                      | Section 4.3       |
>    | request            | application/pkcs7-mime   | Section 4.3.1     |
>    |                    | [RFC5751]                |                   |
>    +--------------------+--------------------------+-------------------+
>    | Cert enroll/renew/ | application/pkcs10       | Section 4.4/4.4.1 |
>    | rekey              | application/pkcs7-mime   | Section 4.4.2     |
>    |                    | [RFC5967] [RFC5751]      |                   |
>    +--------------------+--------------------------+-------------------+
>    | Full CMC           | application/pkcs7-mime   | Section 4.5.1     |
>    |                    | application/pkcs7-mime   | Section 4.5.2     |
>    |                    | [RFC5751]                |                   |
>    +--------------------+--------------------------+-------------------+
>    | Server-side Key    | application/pkcs10       | Section 4.6.1     |
>    | Generation         | multipart/mixed          | Section 4.6.2     |
>    |                    | (application/pkcs7-mime &|                   |
>    |                    | application/pkcs8)       |                   |
>    |                    | [RFC5967] [RFC5751]      |                   |
>    +--------------------+--------------------------+-------------------+
>    | Request CSR        | N/A                      | Section 4.7.1     |
>    | attributes         | application/csrattrs     | Section 4.7.2     |
>    |                    | This RFC                 |                   |
>    +--------------------+--------------------------+-------------------+
>

Finally, you may want to update the references to use HTTPbis instead of 
RFC 2616.

Best regards, Julian

---

From: SM <[email-masked]>
Date: Sun, 11 Nov 2012 09:29:04 -0800

Hi Julian,
At 09:18 11-11-2012, Julian Reschke wrote:
>I can't do a complete review, but here's some editorial feedback on 
>the HTTP related bits:

Thanks for taking a look at the draft.  I am waiting for Mark to get 
back to me.

Best regards,
-sm

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Sun, 11 Nov 2012 17:41:28 +0000

Thank for the time Julian, we'll update the references and tighten the language as you suggest. 

- max

On Nov 11, 2012, at 10:18 AM, Julian Reschke <[email-masked]>
 wrote:

> I can't do a complete review, but here's some editorial feedback on the HTTP related bits:
> 
>> 3.2. HTTP Layer Design
>> 
>> 
> Finally, you may want to update the references to use HTTPbis instead of RFC 2616.
> 
> Best regards, Julian
>

---

From: Barry Leiba <[email-masked]>
Date: Sun, 11 Nov 2012 17:29:27 -0500

> Thank for the time Julian, we'll update the references and tighten the language as you suggest.

Note that you should discuss this with your AD first, before switching
to the HTTPbis references.  While it's the best approach in principle,
it may cause delays in the RFC Editor queue: the HTTPbis documents are
still a few months from IESG approval, I think, and they're building
up quite a cluster for the RFC Editor to deal with.  If you don't mind
that, you should convert the references (the conversion will involve
figuring out which of the six HTTPbis documents each 2616 reference
maps to).  If you want to get the PKIX documents through to RFC
quickly, it might not be worth it.

Sean can advise.

Barry

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Nov 2012 18:44:40 +1100

Done. Let's see how that goes down.

On 12/11/2012, at 4:29 AM, SM <[email-masked]> wrote:

> Thanks for taking a look at the draft.  I am waiting for Mark to get back to me.
> 
> Best regards,
> -sm 

--
Mark Nottingham   http://www.mnot.net/