Original text:
rules used elsewhere in this document, so it is different from PEM.)  The CSR encodes the client's requests with regard to the content of the certificate to be issued.  The CSR MUST indicate the requested identifiers, either in the commonName portion of the requested

Reviewer comments:
The new-certificate transaction should allow the client to request a specific lifetime for a certificate. There is no mechanism in PKCS for this, so it will probably have to be JSON in the message body.
Does it also make sense to allow to specify different classes of certificates? For example, with the Let's Encrypt project, only Domain Validated (DV) certs are supported, but perhaps if ACME can become a standard interface for requesting, managing and exchanging certs to various CAs, a certificate request could indicate a , such as: Domain Validation (DV) Organization Validation (OV) Extended Validation (EV) Naturally the class of cert requested would dictate the types of Identity Authorization challenges that would be issued, so perhaps it would be necessary to specify the class at the time an Identity Authorization is requested to assert that level of certification for that Identity.
Being able to specify a certificate lifetime sees sensible. The server should be free to ignore the request. If one were to request OV/EV certificates, you'd need some way of expressing what organizational information to put on the certificate. Logically this would need to be attached to a validation, which means validations would need to start storing personal/organizational information. One would also need a way to specify the validations to be used when requesting a certificate. Since OV/EV involves paperwork for validation, the value proposition of enabling an automated certificate acquisition protocol for it seems minimal, though it could be useful if CAs were to expose their existing validation systems via ACME. You'd then have certain authorization types the acquisition of which is out-of-scope of the spec.
Organizational information is in the subject name, so it can go in the Subject field of the CSR in the new-certificate message. I agree that there are deeper issues to solve with OV/EV, though.
I think it makes sense that the org info would actually be tied to a registration -- that's the representation of the entity that owns the Identifiers (DNS names) that are later validated. The CSR would actually have the org info and one of the tests that the ACME CA would need to do is make sure that it lines up with what was registered. And then of course the validation that is offered up by the ACME server would need to be of a higher quality or threshold than the ones that are defined today (HTTP, DNS, SNI), but they could even include an "out-of-band" validation, for example that's performed offline. So once that validation is completed, however that takes place, then the client can continue to request certs for that validated Identifier.
A registration doesn't necessarily correspond to an organisation, though. A registration might be capable of representing more than one entity, or the same entity might be represented by multiple registrations, but not want to have to repeat the OV/EV verification process for each registration. I suppose you'd want a new authorization subject type, other than DNS, concerning business information. But there'd need to be some way to grant access from one registration's authorizations to another, or copy them, or something. For example a CDN might want to obtain EV certificates for its customers, but obviously this requires a customer to prove their identity and then delegate that authorization to the CDN, etc.

Revised text:
rules used elsewhere in this document, so it is different from PEM.) <ins> The requested value of the notBefore field in the certificate, in the date format defined in The requested value of the notBefore field in the certificate, in the date format defined in </ins> The CSR encodes the client's requests with regard to the content of the certificate to be issued.  The CSR MUST indicate the requested identifiers, either in the commonName portion of the requested