Subject: Re: [pkix] I-D Action: draft-turner-cmc-serverkeygeneration-00.txt

From: Sean Turner <[email-masked]>
Date: Thu, 27 Mar 2014 14:34:44 -0400

Denis,

Inline…

and a new version is available: http://datatracker.ietf.org/doc/draft-turner-cmc-serverkeygeneration/

spt

On Sep 11, 2013, at 03:44, Denis <[email-masked]> wrote:

> I have several concerns with this proposal which is targeted to the Standards track.

[spt] Again thanks for your review.  You're review resulted in basically a new version of the draft.

> 1. What means compliance to this standard which has a fairly important number of options ? 
> How can interoperability be achieved with so many options ? The document does not address 
> the responses to these questions.

[spt] RAs are optional in RFC 5280 so those scenarios are optional.  With respect to whether AuthData or SignedData are the MTI we think both are MTI and by saying nothing that is the case.  For the server, the main requirement is in section 4:

 Clients and servers MUST support id-cmc-
 shroudWithPublicKey.  Client and servers SHOULD support id-cmc-
 shroudWithSharedSecret.

> 2. The title is: "Server key generation". When reading the text it appears that the right title 
> should rather be : "CA/RA key generation”.

Disagree based on the definition in CMC a server is either the CA or RA, but I can see changing it to:

CMC (Certificate Management over Cryptographic Message Syntax)
Extensions: Server Side Key Generation

> 3. On page 4, a sentence states: " Section 7 describes additional CMC
>    error codes.  Section 8 describes additional exchanges when the
>    server requires the client provide Proof-of-Possession (POP).
>  
> The problem is that the reason(s) to support POP is neither explained here, neither explained 
> in section 8, neither explained in the security considerations section.

As a compromise how about I add a pointer to RFC 4211 from the security considerations for why a CA might want to do POP and add that it's a CP-driven choice:

POP is important; [RFC4211] provides some information about POP; for server-generated keys it can only be provided after the server-generated key has been returned by the client (see Section 8).  Whether a server requires POP is a CP dependent [RFC3647].
 
> 4. There are four basic scenarios. The fifth one is unclear as currently described on page 7.
>  
> The advantages / disadvantages of each method should be clearly advertised. There is one term 
> which should be used: PFS (Perfect Forward Secrecy). Using PFS in this context means that even 
> if a third party managed to intercept a symmetrical key or a private key, then that party can 
> only use the intercepted key in that exchange. Because the next secret key is not based on the 
> previously intercepted key, the third party must begin a new brute force calculation to guess 
> the new key value.
>  
> Scenario 1 does not provide PFS. All others provide PFS.
> Scenarios 2 and 3 are similar in concept:
>   - Scenario 2 uses secret keys.
>   - Scenario 3 uses certificates usable for data authentication.

I took a shot at explaining the scenarios differently by listing the scenario and then explaining the characteristics.  Let me know what you think - see Section 2.

I can buy PFS as a differentiating characteristic but I'm not sure that I completely agree on which scenario gets it but there's text there that we can argue about now.

> 5. The management of a PKI for the clients might prevent the use of scenarios 3 and 4:
>   - Smartcards, smartcard readers and PINs may need to be used.
>   - Otherwise, passphrases will need to be managed and protected.
>   - Clients must have certificates before being able asking certificates 
>     for machines.
>   - Client certificates may need to be checked for revocation.
>  
> These disadvantages are not mentioned, but should be advertised.

So the disadvantages are the typical PKI woes?  I'm not sure we need to include 'em all do we?  Anyway I took a shot at better describing some of the woes/hidden dragons.
 
> Scenario 4 normally requires two certificates belonging to the client: 
> one for authentication and one for encryption.

I think this is already addressed in the text:

 Here, clients can request a certificate with a certificate or
 certificates that the client already has.
 ^^^^^^^^^^^^

> 6. All the scenarios that are described mandate the client, prior to the exchange, either 
> to share a secret with the CA/RA or to already have at least one public key certificate.
>  
> All the scenarios have the following points in common:
>  
>     - a management of all the clients must be performed in advance,
>     - the processing of the requests can be fully automated.

Yes this is true.

> There is another scenario that has different advantages /disadvantages and which requires 
> a manual processing of the requests.
>  
> The main idea is that clients, prior to the exchange, do not need to share any secret with 
> the CA/RA or to already have a public key certificate known or verifiable by the CA/RA.
>  
> Clients only need to know a public certificate (or a public key) for the CA/RA. 
> That certificate is usable for encryption.
>  
> The scenario is as follows:
>  
> The client encrypts the following: the CertRequest (see RFC 5272), the OID of the CP 
> under which the certificate should be issued, an identifier of the type of certificate 
> that is requested under that policy, a secret key to be used by the CA/RA when responding, 
> a derivation method to compute two secret keys when responding, an identifier of the client, 
> an identifier of the request for this client, a cryptographic checksum over the various fields.
>  
> When the CA/RA receives the request, it can only verify that it is a well formed request. 
> Then the client and the CA/RA can use a side channel (out of bands means) where no confidentiality 
> is required to authenticate the request. This may be performed for example using a phone call, 
> a SMS, an email or a combination of the above means.
>  
> Once authentication of the request has been achieved, the server will generate the key pair and 
> the certificate and will derive two keys from the secret key and use one for encryption and 
> the other one for authentication. In this way the client obtains the private key (encrypted 
> under one key) while the response which contains the certificate is authenticated using the 
> other secret key.
>  
> Requests that are not authenticated by clients after X days are simply deleted.
>  
> I would appreciate to have such a scenario added.

My initial thought here was this won't fly because CMC requires that authenticated or signed data encapsulate the PKI data (i.e., it's the outer most siganture) so that would be an update to the base spec.  Jim however pointed out that we could do something that meets your needs with CMC so we added the following:

 While it is generally assumed that the identifier and the
 shared secret are generated by the key generation server and
 then securely transported to the end-entity, there is no
 practical reason why this cannot be done in the opposite
 direction.  In this case the end-entity will generate an
 identifier and shared secret.  When the server receives the
 CMC key generation, it recognizes that it does not correspond
 to an existing identifier/secret pair and puts it on hold.
 The end-entity then communicates the identifier and secret
 to the server.  The server then performs the necessary user
 management dealing with identity validation and certificate
 setup.  If that passes and the secret appears random, then
 the certificate will be issued and the response returned.
 If it does not pass checking then the certificate will fail
 to issue.

I'll try to add some words in to explain this in the appropriate scenarios.

> If scenarios 3 and 4 are maintained, I would propose to clearly separate them from the others 
> and mention that they require a PKI for the clients.
>  
> To summarise:
>  
>   - a scenario 0 which is targeted for human beings and does not rely on a pre-shared secret 
>     or certificates for clients and supports PFS.
>  
>   - a scenario 1 which relies on a pre-shared secret, but does not support PFS.
>  
>   - a scenario 2 which relies on a pre-shared secret and supports PFS.
>  
> Scenarios which require certificates for clients.
>  
>   - a scenario 3 which relies on one certificate and supports PFS.
>  
>   - a scenario 3 which relies on two certificates and supports PFS.

I didn’t do exactly as you proposed but there were significant changes made to the section.  Let us know what you think.

> 7. About scenario 5. I do not think that what is written on page 13 is always applicable :
>  
>    "When the RA generates the key on behalf of the client, the RA
>    effectively becomes a proxy for the client from the CA's perspective.
>    The protocol exchange between the RA and CA is identical to other
>    situations in which a client requests a certificate. 
>  
> Usually the CA trusts the RA and will use a different protocol between them. The diagrams 
> later on shows both the RA and the CA. The introduction should tackle this topic earlier 
> and explain the relationships.

So I've got some of the trust relationship information addressed later but I can see adding it in s5 too.  Let me know what you think about the additions in s2.5 3rd para.

> 8. I have a substantial comment on section 6.1.
>  
>      ServerKeyGenRequest ::= SEQUENCE {
>        certificateRequest  CertTemplate,
>        shroudMethod        ShroudMethod,
>        algCapabilities     SMimeCapabilties OPTIONAL,
>        archiveKey          BOOLEAN DEFAULT TRUE
>        }
>  
> The ASN.1 structure of CertTemplate is not provided, but this structure is described 
> in RFC 5272 as:
>  
>    CertTemplate ::= SEQUENCE {
>      version      [0] Version               OPTIONAL,
>      serialNumber [1] INTEGER               OPTIONAL,
>      signingAlg   [2] AlgorithmIdentifier   OPTIONAL,
>      issuer       [3] Name                  OPTIONAL,
>      validity     [4] OptionalValidity      OPTIONAL,
>      subject      [5] Name                  OPTIONAL,
>      publicKey    [6] SubjectPublicKeyInfo  OPTIONAL,
>      issuerUID    [7] UniqueIdentifier      OPTIONAL,
>      subjectUID   [8] UniqueIdentifier      OPTIONAL,
>      extensions   [9] Extensions            OPTIONAL }
>  
> The text states:
>  
>      o certificateRequest contains the data fields that the client
>        suggests for the certificate being requested for the server
>        generated key pair.  The format is TaggedRequest from [RFC5272],
>        which supports both PKCS#10 and CRMF requests.
>  
> The text should refer to CertTemplate, but refers toTaggedRequest.
> This is incorrect.

Oh wow a great catch - yeah this ought to be pointing to TaggedRequest.

> This structure is however insufficient to cover real use cases in practice.
>  
> It is important to be able to add in ServerKeyGenRequest:
>  
> a) the OID of the CP under which the certificate should be issued. Note: the certificate 
> may contain an extension with anyPolicy, but the CA/RA may still need to know under 
> which CP the certificate should be issued,

The capability to include the CP oid is available in both the PKCS#10 and CRMF.  In PKCS#10, you'd include the certificate policies extension in the extensions attributes and in the CRMF you'd put it in the extensions attribute.
 
> b) an identifier of the type of certificate that is requested under that policy 
> (if there is more than one under that CP).

I'm not sure what you mean by including a OID for the certificate type.

> 9. Section 8 does not explain under which circumstances POP is needed.

I don't think we need to it's up to the server/CP to determine when it is needed.  When the server wants to do POP it uses the mechanism described in s8.

> 10. Section 9 (security considerations) is insufficient and should address PFS. 
> If POP is really needed, section 9 should add a few words.

I think we covered PFS sufficiently in the earlier sections.

I added a pointer to RFC 4211 for POP.
 
> 
> 11. Editorial
>  
> Page 5 uses "shroud methods" and in the next line we have "shrouding methods". 
> Please make it consistent.

fixed

> 12. Typo on page 34 Fourth paragraph, line 2:
>  
> Change:
>  
>    A compromised signature key, when used by the intended party, will
>  
> into
>  
>    a compromised signature key, when used by the intended party, will
> 

fixed

> Denis

Thanks again for the review!

>> Sean,
>> 	I've read through the draft.  It looks like it's much improved over
>> the previous draft.  What's more it seems to make all of the changes you
>> agreed to in your response to Denis (June 1, 2012!).  I'll leave it to Denis
>> to indicate whether he's in agreement, since I don't recall seeing him reply
>> to your response as to whether the proposed changes were agreeable.
>> Certainly there were items you did not agree between the two of you.
>> 
>> 	The draft has a fair number of nits or minor areas that I question.
>> None of them cover the fundamentals of the concept.  Since I collated
>> my input in a Word document, I'm providing that to you under separate
>> cover rather than retyping them into an e-mail as I would do for a
>> Gen-ART review.  Please look them over and feel free to respond to the
>> list with your thoughts.  Or a revised draft would do just fine too. ;-)
>> 
>> 	With the cleanups and clarifications I propose, I'd say that the
>> draft covers my checkboxes for a server-generated key solution.  I'd
>> like to hear what others have to say.
>> 
>> 		-Peter
>> 
>> -----Original Message-----
>> From: 
>> [email-masked] [mailto:[email-masked]
>> ] On Behalf Of Sean
>> Turner
>> Sent: Thursday, August 08, 2013 1:39 PM
>> To: 
>> [email-masked]
>> 
>> Subject: [pkix] Fwd: I-D Action: draft-turner-cmc-serverkeygeneration-00.txt
>> 
>> <no hat>
>> 
>> Here's a revised version of a draft that was formerly a wg draft.
>> 
>> Denis' comments from a while back actually resulted in a complete re-write.
>> Comments are welcome.
>> 
>> spt
>> 
>> <no hat>
>> 
>> -------- Original Message --------
>> Subject: I-D Action: draft-turner-cmc-serverkeygeneration-00.txt
>> Date: Tue, 30 Jul 2013 00:40:01 -0700
>> From: 
>> [email-masked]
>> 
>> Reply-To: 
>> [email-masked]
>> 
>> To: 
>> [email-masked]
>> 
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> 
>> 
>> 	Title           : CMC (Certificate Management over Cryptographic 
>> Message Syntax) Extensions: Server Key Generation
>> 	Author(s)       : Jim Schaad
>>                            Sean Turner
>>                            Paul Timmel
>> 	Filename        : draft-turner-cmc-serverkeygeneration-00.txt
>> 	Pages           : 42
>> 	Date            : 2013-07-30
>> 
>> Abstract:
>>     This document defines a set of extensions to the Certificate
>>     Management over Cryptographic Message Syntax (CMC) protocol that
>>     addresses the desire to support server-side generation of keys.  This
>>     service is provided by the definition of additional control
>>     statements within the CMC architecture.  Additional CMC errors are
>>     also defined.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> 
>> https://datatracker.ietf.org/doc/draft-turner-cmc-serverkeygeneration
>> 
>> 
>> There's also a htmlized version available at:
>> 
>> http://tools.ietf.org/html/draft-turner-cmc-serverkeygeneration-00
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at 
>> tools.ietf.org
>> .
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> 
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
>> _______________________________________________
>> I-D-Announce mailing list
>> 
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> 
>> Internet-Draft directories: 
>> http://www.ietf.org/shadow.html
>> 
>> or 
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> 
>> 
>> 
>> _______________________________________________
>> pkix mailing list
>> 
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
>> 
>> 
>> 
>> _______________________________________________
>> pkix mailing list
>> 
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pkix
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix