[pkix] AD review of draft-ietf-pkix-est

[Sean Turner <[e-mail]>]

I'd like to discuss the following before issuing an IETF LC.  There's no 
implied importance based on the order.  And, yeah there's a lot of 'em 
but I think we're there.

0) s1: r/a CA and/a Certification Authority (CA) and

Expand acronyms on 1st use in body as well as abstract.  Somebody will 
complain.

1) s1 (and elsewhere): "client device" - is "device" needed?

2) s1: (pedantic alert) r/content types/media types

HTTP uses the Content-type header to indicate the media type.  Since you 
already mentioned HTTP headers maybe better to change this to media types.

3) s1: Remove the [[Editor's note ... ]].  They've all been removed 
except this one.

4) s2.1:

OLD:

  The EST client can request a copy of the current EST CA certificates
  from the EST server.

NEW:

  The EST client can request a copy of the current EST CA certificate(s)
  from the EST server.

and delete this from the 2nd paragraph, it's redundant:

  This operation is used to obtain the EST CA certificate(s).

5) s2.6: r/MAC/Media Access Control (MAC)

6) figure 2: r/incorporating/incorporates

and need to add the same caveat to "Full PKI" messages about POP don't 
want people to think one gives you POP while the other doesn't.

7) s3: r/HTTP layers provide/HTTP layers can provide

They don't always but the we're using them they do.

8) s3:

OLD:

  This document also defines transport for CMC [RFC5272] that complies
  with CMC Transport Protocols [RFC5273].

NEW:

  This document also defines transport for CMC [RFC5272] that complies
  with CMC Transport Protocols [RFC5273].  CMC's PoP and
  proof-of-identity mechanisms are defined in CMC, but the mechansisms
  here can also be used in conjunction with those messages in a "Full
  PKI" messages.

I know we don't want to have a long tutorial on CMC here, but the point 
is that there are similar services provided by CMC and they can actually 
be used in conjunction with the mechanisms you've defined here.  I mean 
nothing is stopping that from happening right?

9) s3: I think we should make the following "MAY" a "can":

  End-entities MAY
  have one or more certificates of each type listed

It's not like we're going to be testing this behavior.

10) s3.2.2: You might have seen my question to the uri folks.  Barry's 
recommending that the URIs all be lower case. r/CACerts/cacerts, etc.

11) s3.2.2: What does this mean:

  The EST server
  MUST provide services when the additional path segment is not
  included.

Couldn't a CA refuse to not issue a certificate?  The client asked for 
something unsupported or not in the CA's CP?

12) s3.2.2: r/An EST server MAY provide/An EST server can provide

Not something we'll need to test.

13) s3.2.3: includes the following:

  The client MUST NOT respond
  to the server's HTTP authentication request unless the client has
  authenticated the EST server (as per Section 3.6).

But section 3.6 is about authorization not authentication.  Is s3.2.3 
pointing to the wrong place (i.e., change pointer to s3.3.1 or 3.3.3 if 
the certificate-less option is used) or should authenticated be replaced 
with authorized?

14) s3.2.3: I think we need to make it clear that _NULL_ and _anon_ 
cipher suites are not allowed when doing HTTP-based client 
authentication.  NULL means no confidentiality so the password would be 
passed in the clear and anon just doesn't work with certificate or 
certificate-less authentication.

OLD:

  HTTP Basic and Digest authentication MUST only be performed over TLS
  1.1 [RFC4346] or later versions.

NEW:

  HTTP Basic and Digest authentication MUST only be performed over TLS
  1.1 [RFC4346] or later versions; NULL and anon cipher suites MUST NOT
  be used because they do not provide confidentiality or support mutual
  Certificate-based or Certificate-less authentication, respectively:
  currently these cipher suites include TLS_RSA_WITH_NULL_MD5,
  TLS_RSA_WITH_NULL_SHA, TLS_PSK_WITH_NULL_SHA256,
  TLS_PSK_WITH_NULL_SHA384, TLS_DHE_PSK_WITH_NULL_SHA256,
  TLS_DHE_PSK_WITH_NULL_SHA384, TLS_RSA_PSK_WITH_NULL_SHA256,
  TLS_RSA_PSK_WITH_NULL_SHA384, TLS_ECDH_ECDSA_WITH_NULL_SHA,
  TLS_ECDHE_ECDSA_WITH_NULL_SHA, TLS_ECDH_RSA_WITH_NULL_SHA,
  TLS_ECDHE_RSA_WITH_NULL_SHA, TLS_ECDH_anon_WITH_NULL_SHA,
  TLS_ECDHE_PSK_WITH_NULL_SHA, TLS_ECDHE_PSK_WITH_NULL_SHA256,
  and TLS_ECDHE_PSK_WITH_NULL_SHA384 as well as any that contain
  _anon_.

After thinking about this overnight, I'm not entirely sure we should 
flush _anon_ because a client could do an ordinary TLS handshake without 
client authentication and then do an immediate re-handshake with client 
auth.  Would that still comply with the following text:

  The EST server MUST be authenticated during the TLS handshake unless
  the client is requesting Bootstrap Distribution of CA certificates
  (Section 4.1.1) or Full CMC (Section 4.3).

I mean I guess you could say that you can use _anon_ IFF the very first 
message after the finish is a hello request from the server to do a non 
_anon_ alg?  Then again, who supports _anon_ cipher suites and who does 
rehandshakes?

15) s3.3: I didn't make the leap from the first sentence to the second 
sentence.  TLS is still providing the authentication it's just that in 
the first instance certificates are used and in the second they're not.

OLD:

  The EST server and EST client are responsible for
  ensuring that an acceptable cipher suite is negotiated and that
  bidirectional authentication has been performed.  Alternately,
  certificate-less TLS authentication, where neither the client nor
  server present a certificate, is also an acceptable method for EST
  mutual authentication.

NEW:

  The EST server and EST client are responsible for
  ensuring that an acceptable cipher suite is negotiated and that
  bidirectional authentication has been performed.
  TLS authentication is most commonly enabled with the use of
  certificates [RFC5280].
  Alternately,
  certificate-less TLS authentication, where neither the client nor
  server present a certificate, is also an acceptable method for EST
  mutual authentication.

And, then the last sentence is repeated in two of the three 
sub-sections.  Do we really need to do that?  I'm thinking the repeated 
sentence can be removed from s3.3.1 and s3.3.2.

16) Figure 6/s4.2.3/s4.3.1/s4.3.2: Now that I'm looking at it the 
references for application/pkcs7-mime really needs to be to RFC 5273.  I 
say this because there's additional requirements on the smime-type 
parameter.  I don't think you need to include the smime-type parameter 
in Figure 6 but we definitely need to put it in the subsequent sections.

For s3.2.4:

OLD:

   The EST messages and their corresponding media types are:

NEW:

   The EST messages and their corresponding media types are (parameters
   if any are discussed in the sections noted in the table):

For s4.2.3:

OLD:

  The HTTP content-type of "application/pkcs7-mime" is used.
  The Simple PKI response is sent with a Content-Transfer-Encoding of
  "base64" [RFC2045].

NEW:

  The HTTP content-type of "application/pkcs7-mime" with an smime-type
  parameter "certs-only" is used, as specified in [RFC5273].

For s4.3.1:

OLD:

  The HTTP content-type used is
  "application/pkcs7-mime", as specified in [RFC5273].

NEW:

  The HTTP content-type used is "application/pkcs7-mime" with an
  smime-type parameter "CMC-request", as specified in [RFC5273].


For s4.3.2:

OLD:

  The response data includes
  either the Simple PKI Response or the Full PKI Response as specified
  in Section 3.2 of [RFC5272].

NEW:

  The response data includes either the Simple PKI Response with an
  smime-type parameter of "certs-only" or the Full PKI Response with
  an smime-type parameter "CMC-response", as specified in Section
  3.2 of [RFC5272].

17) s3.3: r/TLS channel binding information MAY be inserted
            /TLS channel binding information can be inserted

It's defined as optional later so no need to repeat that here.

18) s3.3.1/s3.3.2: I think the following should be added where the 
alternative method sentence appeared:

  Cipher suites that contain _anon_ are not appropriate for use because
  they do not provide mutual authentication.

This one has the same caveat wrt to _anon_ as #14.

19) s3.3.3: Are the _SRP_ algs the only one registered so far and will 
all future ones include _SRP_ if that's true then I think we should be 
clear:

OLD:

  TLS-SRP ciphersuites listed in section 2.7 of [RFC5054]
    are suitable for this purpose.

NEW:

  TLS-SRP ciphersuites, i.e., those with _SRP_ in the name, listed in
  section 2.7 of [RFC5054] are suitable for this purpose.

20) s3.5: A little awkward:

OLD:

  Server policy will determine whether the server requires the
  mechanism specified in this section be used by the client.

NEW:

  Server policy will determine whether clients are required to
  support the mechanism specified in this section.

21) s3.5: The challenge-password attribute is limited to 255 characters. 
  Is that sufficient for tls-unique?

   challengePassword ATTRIBUTE ::= {
     WITH SYNTAX DirectoryString {pkcs-9-ub-challengePassword}
     EQUALITY MATCHING RULE caseExactMatch
     SINGLE VALUE TRUE
     ID pkcs-9-at-challengePassword
    }

  pkcs-9-ub-pkcs9String         INTEGER ::= 255
  pkcs-9-ub-challengePassword   INTEGER ::= pkcs-9-ub-pkcs9String

22) s4.1.1: Includes the following:

Also, s4.1.1 contains the following:

  HTTP authentication requests MUST NOT be responded to if the server
  has not been authenticated.

Pointers here would be nice:

  HTTP authentication requests MUST NOT be responded to if the server
  has not been authenticated as specified in Section 3.3.1 or Section
  3.3.3 if the optional Certificate-less authentication is used.

23) s4.1.2: Includes the following:

   The EST server MUST NOT require client authentication or
   authorization to reply to this request.

Is that saying that an EST Server can't refuse to return a CA 
certificate on the /CACerts URI?  Also, what if an EST server really 
wanted to limit who it gave CA certs out too would that break the 
protocol?  What I'm getting at is that I think the MUST NOT is a bit 
harsh and not really an interoperability thing.  I know we keep trying 
to limit the options because it's a PITA to implement a bunch of 
options, but if you can't say why this is a MUST NOT then I think this 
needs to be changed to SHOULD NOT.

24) s4.2.1/s4.2.2: If client is an RA, and it wants to request a 
certificate for another entity that it supports would it use 
/simpleEnroll or /simpleReEnroll?  I ask because I can see an RA 
submitted requests for other clients and it needs to be clear which one 
it should go with.  Right now it seems like it can only happen in 
/simpleReEnroll, but I wanted to make sure my reading of the draft was 
what you intended.

25) s4.2.3: I'm thinking we should define an smime-type here for 
"enrollment-error".  I've got no idea if this will fly, but CMC did it 
so I'd like to follow.  Not wed to the term "enrollment-error".

  A Simple PKI Response with an HTTP
  content-type of "application/pkcs7-mime" (see Section 4.3.2) with
  an smime-type parameter "enrollement-error" MAY be
  included in the response data to convey an error response.

26) s4.2.3: What does this mean:

  The EST client MAY also make the certificate response, and associated
  private key, available to end-entity software for use as an end-
  entity certificate.

Is it saying it'll wrap it up in PKCS#12?  I would have thought that the 
entire point of EST was for the client to give the EE software the 
resulting cert.

27) s4.4 kicked it off but it has legs: (I'd read this one entirely 
before commenting) Includes the following:

  A client MUST authenticate and authorize an EST server as specified
  in Section 3.3.1, Section 3.6, and Section 3.3.3.

Shouldn't it be:

  A client MUST authenticate and authorize an EST server as specified
  in Section 3.3.1 or Section 3.3.3 and Section 3.6, respectively.

3.3.1 and 3.3.3 are about authentication which 3.6 is about 
authorization.  Maybe just better to keep 'em together.

and ditto for the next paragraph about server authenticating/authorizing 
the client.

Okay wait a minute, what's the MUST implement authentication mechanism 
for the server?  I assume it's s3.3.1 right?  This sentence from s3.3.1 
doesn't entirely get that across:

  The EST server MUST be authenticated during the TLS handshake unless
  the client is requesting Bootstrap Distribution of CA certificates
  (Section 4.1.1) or Full CMC (Section 4.3).

and text in s4.1.2, s4.2, s4.4 doesn't clear it up.

The 1st paragraph in s3.3.1 needs to read more like 1st paragraph in 
s3.3.2, but it needs to say certificate authentication is the MUST and 
the other is optional.  I mean everybody does server side authentication.

For s3.3.1, add the following new 1st sentence to the 1st paragraph:

  TLS server authentication with certificates MUST be supported.

Isn't the following in s3.3.1 applicable to clients as well?:

  EST server MUST be authenticated during the TLS handshake
  unless the client is requesting Bootstrap Distribution of CA
  certificates (Section 4.1.1) or Full CMC (Section 4.3).

If so then maybe move it to s3.3.

For s4.1.2: It's not s3.3.1 and s3.3.3 it's or right I mean we'd not do 
both certificate and certificate-less authentication?

OLD:

  The client MUST authenticate the EST server as specified in
  Section 3.3.1 and Section 3.3.3 and check the server's authorization
  as given in Section 3.6 or follow the procedure outlined in
  Section 4.1.1.

NEW:

  The client MUST authenticate the EST server as specified in
  Section 3.3.1 if Certificate-based authenticated is used or
  Section 3.3.3 if the optional Certificate-less authentication
  is used and check the server's authorization as given in
  Section 3.6 or follow the procedure outlined in Section 4.1.1.

For s4.2: and is also the wrong word here it's or.

OLD:

  The client MUST authenticate the EST server
  as specified in Section 3.3.1 and Section 3.3.3.

NEW:

  The client MUST authenticate the EST server
  as specified in Section 3.3.1 if Certificate-based authenticated
  is used or Section 3.3.3 if the optional Certificate-less
  authentication is used.

and:

OLD:

  The server MUST authenticate the client as specified in
  Section 3.3.2 and Section 3.3.3.

NEW:

  The server MUST authenticate the client as specified in Section
  3.3.2 if Certificate-based authentication is used or Section
  3.3.3 if the optional Certificate-less authentication is used.

For s4.4:

OLD:

  A client MUST authenticate and authorize an EST server as
  specified in Section 3.3.1, Section 3.6, and Section 3.3.3.

NEW:

  The client MUST authenticate the EST server as specified in
  Section 3.3.1 if Certificate-based authenticated is used or
  Section 3.3.3 if the optional Certificate-less authentication
  is used and check the server's authorization as given in
  Section 3.6.

OLD:

  The EST server MUST authenticate and authorize the client as
  specified in Section 3.3.2, Section 3.7, and Section 3.3.3.

NEW:

  The server MUST authenticate the client as specified in
  Section 3.3.2 if Certificate-based authenticated is used or
  Section 3.3.3 if the optional Certificate-less authentication
  is used and check the server's authorization as given in
  Section 3.7.

28) s4.4: Hmm I'd say the CA that the EST servers has something to say 
about keeping a copy of the key:

   r/server storage of generated keys is a local option
    /server archive of generated keys is determined by CA policy

29) s4.4: Need to specify that _NULL_ cipher algs are a MUST NOT here:

  Cipher suites which have a NULL confidentiality algorithm MUST
  NOT be used as they will disclose the contents of the
  unprotected private key; currently these cipher suites
  include TLS_RSA_WITH_NULL_MD5,
  TLS_RSA_WITH_NULL_SHA, TLS_PSK_WITH_NULL_SHA256,
  TLS_PSK_WITH_NULL_SHA384, TLS_DHE_PSK_WITH_NULL_SHA256,
  TLS_DHE_PSK_WITH_NULL_SHA384, TLS_RSA_PSK_WITH_NULL_SHA256,
  TLS_RSA_PSK_WITH_NULL_SHA384, TLS_ECDH_ECDSA_WITH_NULL_SHA,
  TLS_ECDHE_ECDSA_WITH_NULL_SHA, TLS_ECDH_RSA_WITH_NULL_SHA,
  TLS_ECDHE_RSA_WITH_NULL_SHA, TLS_ECDH_anon_WITH_NULL_SHA,
  TLS_ECDHE_PSK_WITH_NULL_SHA, TLS_ECDHE_PSK_WITH_NULL_SHA256,
  and TLS_ECDHE_PSK_WITH_NULL_SHA384.

30) s4.4.1: r/the request must be/the request MUST be

31) s4.4.1.2: I think you need to add:

  The key identified MUST either explicitly support keyTransport or
  keyAgreement or its use MUST be unrestricted.

32) s.4.4/s4.4.1.*/s4.4.2.*/s7/s8.2: The bit of text about not wrapping 
the keys with AES key wrap got me to thinking.  The algorithms the 
client supports need to either be known by the server before it asks for 
a key or the client needs to tell the server which one it supports.  I 
also think we need to make the recommendation about protecting the 
server-generated keys protected MUCH earlier than the security 
considerations.

In s4.4.1,

OLD:

  If the client desires to receive the private key with encryption that
  exists outside and in addition to that of the TLS transport used by
  EST or if server policy requires that the key be delivered in such a
  form, the client MUST include an attribute in the CSR indicating the
  encryption key to be used.

NEW:

  If the client desires to receive the private key with encryption that
  exists outside and in addition to that of the TLS transport used by
  EST or if server policy requires that the key be delivered in such a
  form, the client MUST include an attribute in the CSR indicating the
  encryption key to be used.  Both symmetric and asymmetric encryption
  are supported as described in the following subsections.

  In addition, either the server needs to know a priori about the
  algorithms supported by the client or the client needs to indicate
  its supported algorithms in the request.  To indicate the algorithms
  supported, the client includes the SMIME Capabilities [RFC5751]
  attribute in the CSR.  The algorithm listed MUST include an algorithm
  that corresponds to the key indicated in the attributes found in
  s4.4.4.1 or s4.4.4.2 as well as a key encryption algorithm.  Encodings
  for SMIME Capability values for Elliptic Curve Key Agreement, Key
  Derivation Function, and Key Wrap algorithms can be found in
  [RFC5753], Message Digest and Signature algorithms can be found
  in [RFC5754], and AES Key Wrap with Padding can be found in [RFC5959].

  It is strongly RECOMMENDED that the clients request that the returned
  private key be afforded the additional security of the CMS
  EnvelopedData in additional to the TLS-provided security to
  protect against unauthorized disclosure.

In s4.4.2,

  r/The SignedData is signed by the party
   /The SignedData is applied by the party

  r/The SignedData is further protected inside of
    a CMS EnvelopedData
   /The SignedData is further protected by placing it inside of
    a CMS EnvelopedData

In s4.4.2, kekri supports symmetric encryption so no need for ori:

  r/The
    EnvelopedData RecipientInfo field MUST indicate the ori (Other
    Recipient Info) key management technique.  The oriType will be
    set to TBD and the oriValue will be set to TBD.
   /The
    EnvelopedData RecipientInfo field MUST indicate the kekri (Key
    Encryption Key Recipient Info) key management technique.  The
    values are: version is set to 4, kekid is set to the value of
    the DecryptKeyIdentifier from Section 4.4.1.1,
    keyEncryptionAlgorithm is set to one of the key wrap algorithms
    that the client included in the SMIME Capabilities accompanying
    the request, encryptedKey is the encrypted key.

In s4.4.2, a couple of tweaks required for ktri.  Basically, I'm not 
sure why you'd ignore the recipient key identifiers the client gave it 
to the server in the attribute.  The client might provide the whole 
certificate actually to the client in the OCTET STRING and then the 
server can pick whether to do the issuer and serial or the subject key 
identifier.

NEW (replace the entire bullet):

  If the client specified an asymmetric encryption key suitable for
  key transport operations to protect the server-generated private
  key, the EnvelopedData content is encrypted using a randomly-
  generated symmetric encryption key.  The cryptographic strength
  of the symmetric encryption key SHOULD be equivalent to the
  client-specified asymmetric key.  The EnvelopedData RecipientInfo
  field MUST indicate the ktri (KeyTransRecipientInfo) key
  management technique.  In KeyTransRecipientInfo, rid is either the
  subjectKeyIdentifier copied from the attribute defined in Section
  4.4.1.2 or the server determines an associated issuerAndSerialNumber
  from the attribute.  version is derived from the
  choice of rid [RFC5652], keyEncryptionAlgorithm is set to one of the
  key wrap algorithms that the client included in the SMIME Capabilities
  accompanying the request, and encryptedKey is the encrypted key.

In s4.4.2, a couple of tweaks required to kari:

NEW (replace the entire bullet):

  If the client specified an asymmetric encryption key suitable for
  key agreement operations to protect the server-generated private
  key, the EnvelopedData content is encrypted using a randomly-
  generated symmetric encryption key.  The cryptographic strength
  of the symmetric encryption key SHOULD be equivalent to the
  client-specified asymmetric key.  The EnvelopedData RecipientInfo
  field MUST indicate the kari (KeyAgreeRecipientInfo) key
  management technique.  In KeyAgreeRecipientInfo, version,
  originator, and ukm are as in [RFC5652] and
  keyEncryptionAlgorithm is set to one of the key wrap algorithms
  that the client included in the SMIME Capabilities accompanying
  the request.  The recipient's key identifier is either copied
  from the attribute defined in Section 4.4.1.2 to
  subjectKeyIdentifier or the server determines an
  IssuerAndSerialNumber that corresponds to the value provided in
  the attribute and.

In s7,

OLD:

  The server-side key generation method allows keys to be transported
  over the TLS connection to the client.

NEW:

  The server-side key generation method allows keys to be transported
  over the TLS connection to the client without any application layer
  protection.

In s8.2, add informative references to 5753, 5754, and 5959.

33) s4.4.2: I think we need to add something about the smime-type:

OLD:

  In all three additional encryption cases, the EnvelopedData is
  returned in the response as an "application/pkcs7-mime" part with a
  Content-Transfer-Encoding of "base64".

NEW:

  In all three additional encryption cases, the EnvelopedData is
  returned in the response as an "application/pkcs7-mime" part, with
  an smime-type parameter of "server-generated-key", and with a
  Content-Transfer-Encoding of "base64".

34) s4.5.2: I've been wondering whether the inclusion of a bunch of 
random OIDs really makes sense.  The client's going to need to know an 
awful lot about what that OID means.  Wouldn't it be better to return 
the actual structure for the thing you want to include and then let the 
client fill it in? That is instead of:

   Csrattrs ::= SEQUENCE SIZE (0..MAX) OF OBJECT IDENTIFIER { }

we'd have:

   Csrattrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

   AttrOrOID ::= CHOICE {
	oid	OBJECT IDENTIFIER,
	attribute Attribute }

That way if somebody wants to just ship the OID for the attribute they 
can, but if you want to ship more that's okay too. Like for example, I'd 
not just ship the OID for secp384r1, I'd ship id-ecPublicKey with 
parameters.

35) s7: If you'd of pointed to TLS 1.2 I'd let this one go but you 
didn't.  We need to kill of the export algs.  Add:

  Cipher suite that include "_EXPORT_" and "_DES_" MUST NOT be used.
  These ciphers do not offer a sufficient level of protection; 40-
  bit crypto in '13 doesn't cut the mustard and the use of DES is
  deprecated.

36) A.1: shouldn't:

GET /CACerts HTTP/1.1

be:

GET /.well-known/est/CACerts HTTP/1.1

37) A.*: I think some headers are missing:

Content-Type needs to include the smime-type parameter where appropriate.

For A.1/.2/.3:

r/Content-Type: application/pkcs7-mime
  /Content-Type: application/pkcs7-mime; smime-type=certs-only

38) A.1: cert bag message.  I know this is a bit of nit-nod comment but 
can we have the example certificates more closely align with 5280 :) The 
certificates need to include a critical key usage extension with key 
cert sign and crl sign set.  And the basic constraints extension needs 
to be critical as well?

39) A.2/.3: request needs to include a challenge response password with 
tls-unique. response should drop the basic constraints extension and 
include a critical key usage extension

40) Any chance we can specify that query and fragment components of URIs 
MUST be omitted?

41) Should the HTTP Informational and Redirect codes result in a 
terminated session?  Are there any security considerations that result 
from a server redirect?

spt