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

From: "Peter Yee" <[email-masked]>
Date: Mon, 9 Sep 2013 21:00:34 -0700

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

---

From: Denis <[email-masked]>
Date: Wed, 11 Sep 2013 09:44:03 +0200

**

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

**

**

*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.*

**

**

*2.****The title is: "Server key generation". When reading the text it 
appears that the right title
should rather be : "CA/RA 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.*

**

**

*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.*

**

**

*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.*

**

*Scenario 4 normally requires two certificates belonging to the client:
one for authentication and one for encryption. *

**

**

*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.*

**

*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.*

**

*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.*

**

**

*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.*

**

**

*8.****I have a substantial comment on section 6.1.*

**

*ServerKeyGenRequest ::= SEQUENCE {*

*certificateRequestCertTemplate,*

*shroudMethodShroudMethod,*

*algCapabilitiesSMimeCapabilties OPTIONAL,*

*archiveKeyBOOLEAN 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 to 
**TaggedRequest**. *

*This is incorrect. *

**

*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,*

**

*b) an identifier of the type of certificate that is requested under 
that policy
(if there is more than one under that CP). *

**

**

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

**

**

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

**

**

*11.****Editorial*

**

*Page 5 uses "shroud methods" and in the next line we have "shrouding 
methods".
Please make it consistent.*

**

*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*

Denis

---

From: Sean Turner <[email-masked]>
Date: Mon, 16 Sep 2013 20:13:27 -0400

Denis,

Working on these with my co-authors.  Will get back to you.

spt

On 9/11/13 3:44 AM, Denis wrote:
>> From:[email-masked]  [mailto:[email-masked]] On Behalf Of Sean
>> Turner
>> To:[email-masked]
>> From:[email-masked]
>> Reply-To:[email-masked]
>> To:[email-masked]
>>
>>
>> Internet-Draft directories:http://www.ietf.org/shadow.html
>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>