Subject: RE: New CMC Draft available

From: Carlisle Adams <[email-masked]>
Date: Mon, 15 Mar 1999 18:41:56 -0500

Hi,

> ----------
> From: 	Jim Schaad (Exchange)[SMTP:[email-masked]]
> Sent: 	Monday, March 08, 1999 1:12 PM
> To: 	IETF-PKIX (E-mail)
> Subject: 	New CMC Draft available
> 
> A new draft of CMC (what will become draft -03) is now available on-line.
> This draft should appear on the various IETF servers shortly after the
> upcoming meeting in Minneapolis.  We apologize for missing the
> internet-draft cutoff date to get the draft published on IETF servers
> before
> the meeting; in the meantime the draft is available in various format from
> Brian LaMacchia's personal website at:
> 
> 	http://www.farcaster.com/cmc/
> 
> The differences between the -02 and -03 drafts may be summarized as
> follows:
> 1) New Section 5.3, Linking Identity and POP information, to address the
> potential theft/replay attack involving cert requests with NULL subject
> DNs
> that Carlisle Adams pointed out.
> 2) Revised Section 5.7, POP for Encryption-only Keys, to address a similar
> attack involving the example state-reduction technique.
> 3) Numerous editorial changes that were made in response to comments
> posted
> to the list and/or delivered to the authors privately.
 
Congratulations to all authors and contributors on this revision; the
improvements over the previous draft are significant!  In particular, it
appears that the modifications to Sections 5.3 and 5.7 address my earlier
concerns so that an entity may now be securely initialized into the PKI
using this protocol.

I have a few additional comments but, in order to save bandwidth on the
list, perhaps I'll send the minor editorial ones (typos, wording
clarifications, etc.) privately to the authors.  The rest are included
below.

Abstract:  there is not a *need* for an interface to PK certification
products and services based on [CMS] and [PKCS10]; there is a *desire* for
such an interface.  Nothing *needs* to be based on CMS and PKCS10
(especially since, as noted in the conformance section, existing deployed
software is not immediately compliant with this specification).  However,
there is great *desire* to base the protocols on CMS and PKCS10, since these
are familiar.  Please change "need" in bullet 1 to "desire" (and change
"immediate needs" in the opening sentence to "immediate concerns", or
similar).

Section 2, Section 2.1, and elsewhere:  the document sometimes uses
"certificate authority", sometimes uses "certification authority", sometimes
uses "Certification Authority", and so on.  Please be consistent throughout.
[Note that "Certification Authority" is the official term in various
Standards.]

Section 2:  this may be obvious to many, but I think that stating the
following underlying operational assumption will help to clarify the
operational model for this protocol.  "Underlying assumption:  every PKI
entity will have a signing key pair and will request a verification
certificate in its initialization message (i.e., an entity will never ask
for an encryption certificate _only_ in its initialization message)."  [The
reason that it might help to clarify this is that RFC 2510 does not have
this restriction.]

Section 3.3.3.1:  "D-H private keys cannot always be used..." -- note that
is may also be true for RSA keys that are held in a decrypt-only device, so
you need not restrict this section to D-H.

Also, "NoSignatureValue contains the hash of the certification request." --
why force the implementer to do an extra hash here for no purpose?  Why not
say that NoSignatureValue "contains the value 1234", or similar?

Section 5.2 (second paragraph):  "Servers SHOULD provide this method or have
a bilateral method..." -- I would prefer the following for interoperability
reasons:  "Servers MUST provide this method and MAY also have a bilateral
method...".

Section 5.7:  should note in first paragraph that PKCS10 cannot be used to
provide this functionality.

Also, it appears (from the text in bullet 4a and the text in the second-last
sentence of the section) that the DecryptedPOP structure should contain
"request    TaggedRequest" rather than "bodyPartID    BodyPartID".  That is,
the decrypted POP needs to contain the actual request itself (not just an
ID).

Section 5.9 (last paragraph):  "the server responds with a Key Recovery
Response containing the newly generated key." -- it doesn't really make any
sense semantically to use a key recovery response to implement off-client
key generation (since off-client key generation is not key recovery).  Why
not simply define a new message ("OffClientKeyGenRep") with the same syntax
as Key Recovery Response?

Also, "The details of the request control statement not covered in this
document...".  This will limit the use of this protocol in some environments
(those that mandate central key gen.).  A request message needs to be
defined for this purpose.

Section 5.9.3:  "The ContentInfo contains the requested private key
material." -- does it also contain the newly-created recipient (i.e., EE)
certificate?  If not, how can this response be used for off-client key
generation?  [Note that according to CMS, it is not clear that it's legal
for a CA to put the EE certificate in this construct....]

Sections 5.9.4.1, 5.9.4.2, 5.9.4.3:  in each section you need to say that
the private key (DH-PrivateKey, DSA-PrivateKey, or RSAPrivateKey) must
subsequently be re-encoded as an OCTET STRING (in order to fit within the
structure defined in Section 5.9.4).

Section 5.10:  "low-end IP router that does not retain its own certificate
in non-volatile memory".  I might prefer "low-end IP router that does not
retain in non-volatile memory the certificates of those entities with whom
it needs to communicate".  Entities certainly need to get the certificates
of others in order to talk with them; do they really need to keep their own
certificates for most of their activities?

Section 5.11:  "The fields in a GetCRL have the following meanings:  --
issuerName is the value of the Issuer DN in the subject certificate."  This
will not work for Indirect CRLs.  Perhaps this field should hold the name of
the CRL issuer instead...

Section 5.12:  "it is impossible to produce a reliable digital signature."
-- this should be clarified to "it is impossible to produce a reliable
digital signature (prior to the certification of a new signature key pair)."

Section 5.14:  "The query pending attribute allows for a client to query a
server about the state..." -- how does the client know when to do this?  Is
there a time-to-check-back value included somewhere in the server's
response?

Section 6.1:  "The request is placed in the cmsSequence if it is a full pki
message and the reqSequence field for a simple enrollment message." -- in
the latter case, is this still a nested message?  (I.e., what is the
difference between a "non-nested" message with a PKCS10 in the reqSequence
and a "nested" message with a simple enrollment message in the reqSequence?)

Sections 7.2, 7.3:  replace "BER" with "DER" since signatures are
involved...

Section 12:  update the CRMF reference to RFC 2511 and the PKIXCERT
reference to RFC 2459.  Also, was DH-SIG not updated to some other draft
recently?

Finally, there is some  functionality missing in this specification that
will be very important for some environments.

- there is currently no way for a CA/RA to provide a trust anchor (public
key or self-signed cert) to the client during initialization.

- there is no confirmation message from the client to the CA/RA (thus, there
is no way for a client to reject a certificate that it does not want (e.g.,
in the case where the CA has modified some of the fields in the request)).

- cross-certification is not described.  (It appears to be possible to do
this with the existing messages, but without a prescribed method
interoperability is unlikely.)

- as mentioned above, off-client key generation needs to be specified (both
request and response).  It would also be nice to be able to ask for this as
part of the Full PKI Request message, rather than having to use separate
req/rep messages.

- CA key rollover is not described.  (This might be considered to be
out-of-scope of the current document, but it is very much in-scope for a
specification on how to do comprehensive certificate management, which is
what the title of this document suggests.)

That's all.  Aside from a few other typos, etc., the document looks great!

Carlisle.

---

From: Juergen Walter <[email-masked]>
Date: Thu, 18 Mar 1999 13:19:50 +0100

I would like to stress the initial registration procedure (section 5.3).
Thanks to the authors and contributors for CMC review and improvement.
But I have still a concern. Unless otherwise stated initial registration
protocols defined in CMC and CMP are considered. 

Supposed that the initial registration message is not encrypted,
off-line guessing attacks may appear. The weakness comes from the fact
that the input data (plaintext) for the HMac algorithm is sent together
with its cipher text. The adversary may confirm before the CA or RA
receives the message. The probability of guessing the initial
authentication key is nearly one if the adversary has enough time.

There are the following three consequences:
1) The initial authentication key is only suitable for short-term usage.
2) Supposed an adversary can intercept the connection to the CA or RA
the adversary can reformulate entity´s certificate request.
3) An adversary can apply for a certificate with changed request data
even if he is not able to intercept the connection between end entity
and CA.

The initial authentication key distribution is commonly a cost-intensive
procedure. I assume for the following that the initial authentication
key is an identifier for the individual entity. It might be a good idea
to use this initial authentication key for further off-line
authentication procedures e. g. certificate revocation request.

I consider for example that the adversary may replace entity´s public
key by its own. The following cases may be considered:

Case 1. I assume that the adversary can intercept any connection between
the certificate applicant and the CA. The CA issues a certificate that
contains applicant´s identity and adversary´s public key. The applicant
may miss his certificate but he may think that is an operational issue.
The concerned entity may phone on the CA. Consequently, cost-intensive
back office procedures have to start. CMP users are in the comfortable
position that they have to be silent when they do not confirm. In the
meantime the adversary can confirm whereby he applies the initial
authentication key again. The adversary has probably a fake certificate
for the whole validity period. (Note: If there is no control over
initial authetication key expiry in the CA domain the entity may
re-certified in addition. But the adversary has still a fake certificate
containing entity´s identity and adversary´s public key.) I propose to
add a message to both the CMP and CMC protocol that allows the applicant
to retrieve the certificate after a time-out specified by local policy.
The response then contains the issued certificate, a waiting or an error
message. Now the applicant can validate the received certificate and
send his confirmation. The validation must include a check that the
public key in entity´s
certificate matches entity´s private key. Additionally, I propose an
explicite non-confirmation message.

Case 2. I assume that the adversary is not able to intercept the
connection between the CA and the end entity. Depending on the controls
implemented by the CA no, one or two certificates will be issued. The CA
will detect the attack when it takes appropriate control over the
initial authentication key management. The initial authentication key
must be a unique and one-time password that corresponds to an individual
entity. Nevertheless the end entity must validate that the issued
certificate contains the public key matching entity´s private key.
Therefore an explicit non-confirmation message would be meaningful.

A security measure against this offline-guessing attack is the
encryption of the initial registration. Please add an appropriate
recommendation to the CMC and the CMP draft.

There are initial registration protocols that provides a higher level of
security. For example the HMac is taken over data that is not completely
known by a potential adversary. Then he is not able to verify his guess
because he does not know the complete plain text. In the case of
signature algorithms with message recovery the certificate applicant may
include a self-choosen password that is contained in HMac input as plain
text. But this password is contained in the initial registration request
as cipher text where it is encrypted by e. g. CA´s public key. The
password is not contained as plain text in the initial registration
request at all. This password chosen by the entity may serve for
authentication purposes in revocation requests. Unfortunately the schema
is not applicable for signature algorithms like DSA. It has to be
re-designed. Replace the one-directional delivery of an initial
authentication key prior to the initial registration by an out-of-band
exchange of keys or passwords i. e. the following out-of-band procedures
take place before an end entity sends his initial registration message:

CA->EE: initial authentication key, other initial data
EE->CA: password
 
This causes no additional expenses in such registration scheme where the
end entity is well-identified by some agent. Nowadays it is commonly
applied by GSM phone sellers.

I think that the current CMP and CMC draft does not support the scheme
described above. Is a support of the described scheme planned for next
CMP and CMC reviews? Is someone else interested in such scheme?

Juergen

-- 

with regards

--------------------------------------------------------------------
Juergen Walter                  PoP Leipzig/Halle/Jena
DEH information systems GmbH    WWW: http://www.deh.de
Weissenfelser Strasse 46a       Germany
D-06217 Merseburg               Tel.: +49 3461 3318-25
Email: [email-masked]            Fax:  +49 3461 415072
--------------------------------------------------------------------