Subject: RE: CMC Comments?

From: Carlisle Adams <[email-masked]>
Date: Tue, 5 Jan 1999 12:49:09 -0500

Hi Brian,

Now that I'm back after a long (but way too short!) Christmas break, let me
jump in and address a couple of your points below.

-----Original Message-----
From: Brian LaMacchia [mailto:[email-masked]]
Sent: Wednesday, December 23, 1998 5:59 PM
To: 'Luke Koops'
Cc: [email-masked]; Barb Fox (Exchange)
Subject: RE: CMC Comments? 

Luke--

(...stuff deleted...)

	4) The absence of a client confirmation message means that there is
no way to
	be sure that a client recieved a response, or that a client accepts
the
	response.

In what particular scenarios do you believe a confirmation message is
required?  In particular, could you expand on what it means for a client to
"accept the response?"  I know that CMP uses the client confirmation message
as means of doing after-the-fact POP on an encryption key (the "indirect
method" defined in section 2.3.2): the cert is issued to the encryption key
before POP, the cert is returned to the client encrypted, the client
demonstrates POP by decrypting the encrypted cert, and failure to respond
requires that the CA now revoke the cert it just issued.  CMC takes the
approach that the cert should not be issued in the first place unless CA
policy has been completely satisfied (e.g. POP for encryption keys
demonstrated before the request is granted); this avoids extraneous
revocations.

<Carlisle> Actually, CMP does not specify that "failure to respond requires
that the CA now revoke the cert it just issued" (in fact, it suggests
exactly the opposite -- see the final sentence of Section 3.3.4 -- because
an encrypted certificate is of no use to anyone without the key to decrypt
it, so it does not need to be revoked).  However, POP for encryption key
pairs is not the reason that CMP specifies a confirmation message.  Recall
that the CA has the power/authority/privilege/prerogative/etc. to modify the
fields of any cert request that arrives.  The confirmation message allows
the EE to accept or deny the generated certificate, based upon whether or
not any changes made are acceptable to it.  Such a function is not merely
"nice-to-have"; it may be legally required in some environments.
Additionally, the confirmation message may simply be used to show that the
EE did, in fact, receive the certificate, triggering the CA to make the
certificate publicly available by some appropriate means.

<Carlisle> The fact that the confirmation message could simultaneously be
used for proof-of-possession of a decryption key was a happy coincidence
that CMP was pleased to exploit in order to achieve POP for all types of key
pairs without requiring any extra messages.

	p.1, item 1 in Abstract:  "need" should be replaced with "desire".

I respectfully disagree :-), as there is clearly a need within the community
to standardize current industry practice, as has long been identified within
the PKIX WG.

<Carlisle> I respectfully disagree with your respectful disagreement.  :-)
Something that is really "current industry practice", something that is
actually done by many/most products now, is already a de facto standard and
does not *need* to be standardized.  What needs to be standardized is the
next step, the next level of functionality addressing greater generality or
different environments (so that people know what to build).  I can
understand that there may be a *desire* to standardize current practice,
simply to formalize it and get it written down in concrete,
widely-accessible documents, but this is not actually a *need* if everyone
has already implemented it the same way (of course, if they *haven't*
implemented it the same way, then there really isn't "current industry
practice", is there?).  But this is a very minor quibble.

	p.2, section 2:  "The two different request messages" should be
replaced
	with "The three different request messages".

There are only two different request messages: Simple Enrollment Request and
Full PKI Request.  What is the third?

<Carlisle> Simple Enrollment Request, Full PKI Request (using PKCS #10), and
Full PKI Request (using CRMF) seem like three messages, but for me this is a
minor quibble as well.

	p.7, section 3.3.2 [see also p.6, section 3.3.1]:  MUST include both
the
	subject name and public key fields, although the subject may be
NULL.  There
	is an attack here on the initialization mechanism whereby I can copy
	somebody else's request and then send in my own request, ending up
with
	their public key and my identity in a valid verification
certificate.  In
	other words, the initialization mechanism is not secure.

This has already been pointed out by Carlisle in his previous list comments;
the authors are currently evaluating a number of proposals to nullify
self-inflicted denial-of-service attacks, including this one.

<Carlisle> The attack mentioned here is not a "self-inflicted
denial-of-service" attack.  It allows me to get my name and your
verification key put into a certificate which allows me, for example, to
(legally) claim as mine documents that you have signed, or to substitute
your certificate for mine in an authentication protocol that you are
engaging in such that the other party thinks it is communicating with me.
This is not denial-of-service stuff.

	p.7, section 3.3.3:  "[DH-SIG] provides a way to product necessary
	signature."  Change "product" to "produce the".  Also, note that
this
	mechanism is not strictly conformant with PKCS #10, which is very
explicit
	about how you sign the request.

This grammar will be fixed in the next draft.  As for the signature in a
PKCS#10, I'm not sure I understand your point.  PKCS#10 (as available at
ftp://ftp.rsa.com/pub/pkcs/doc/pkcs-10.doc, and as structurally included in
CMC) defines a CertificationRequest as a SEQUENCE of
CertificationRequestInfo, SignatureAlgorithm (an AlgorithmIdentifier) and a
Signature (BIT STRING), equivalent to the X.509 SIGNED macro.  All we need
to do is define the AlgorithmIdentifier and semantics of the Signature BIT
STRING for whatever DH-SIG ends up using.

<Carlisle> While syntactically conformant, such an interpretation of
"signatureAlgorithm" and "signature" are not strictly conformant with PKCS
#10 because the semantics are very different.  Section 6.2 of PKCS #10
(specifically the 3rd bullet and the 2nd step) make this clear, especially
when combined with Section 3.1 of the document "An Overview of the PKCS
Standards", which defines digital signature.  Again, however, this is a
relatively minor quibble, since in Orlando it was agreed that the
terminology "Diffie-Hellman *signature*" would no longer be used.

	p.9, section 4.2:  it seems to me that digging into the bowels of a
message
	in order to verify the outer envelope is a violation of the intent
of
	CMS/PKCS7.  Is there really no way to avoid this layering mismatch?

Somehow you need to get a copy of the public component of the signature key
pair in order to verify the signature.  CMS provides two types of hints in
SignerInfo to help you try to find the right key: an Issuer&SerialNumber
pointer and a SubjectKeyIdentifier value (SKI was just added in Orlando).
In S/MIMEv3 use, the I&SN identifies a cert for the corresponding public
key, and typically a copy of that cert will be included in the
CertificateSet.  if you're signing your Full PKI Request with a
previously-certified key that works fine.  However, this approach doesn't
work in CMC if you're signing the Full PKI Request with one of the key for
which you are requesting certification.  That's why draft -02 overloaded
I&SN, putting the bodyPartID in the SN slot and NULL IssuerName.  In the
next draft CMC will take advantage of the SKI form to identify a particular
key contained within the message.

<Carlisle> Taking advantage of the SKI to identify a particular key within
the message does not address the question asked.  The point is still that
you need to dig into the contents of the message before you can verify the
outer envelope for initialization messages.  This seems to be a layering
mismatch and seems to violate the intent of CMS/PKCS7.

	p.22, section 5.10.4.1:  "DH-PrivateKey ::= INTEGER" should be
	"DH-PrivateKey ::= INTEGER, re-encoded as an OCTET STRING" (written
in valid
	ASN.1).

	p.22, section 5.10.4.2:  "RSAPrivateKey" should be "RSAPrivateKey,
	re-encoded as an OCTET STRING" (written in valid ASN.1).

I don't understand this; are you asking for the INTEGER to be wrapped within
an OCTET STRING?  Why?  PKIX Part 1 uses INTEGER for the public components
of DSA an DH, and RSAprivate is pulled directly from PKCS#1.

<Carlisle> This comes from the definition of PrivateKeyInfo on the top of
page 22, where privateKey is defined to be an OCTET STRING.  In Sections
5.10.4.1 and 5.10.4.2 it says that privateKey must be INTEGER and
RSAPrivateKey, respectively, but in order for these to fit into the
specified PrivateKeyInfo structure, they must be re-encoded as OCTET
STRINGs.

Hope everyone else had a great Christmas as well!

Carlisle.

---

From: Luke Koops <[email-masked]>
Date: Fri, 8 Jan 1999 13:29:47 -0500

Thanks to Carlisle for responding to many of your comments.  I will attempt
to reply to the few remaining outstanding issues.  I have deleted the
sections of the original message to which I am not responding.  Hopefully
the result is readable and fair.

-Luke Koops
[email-masked]

> ----------
> From: 	Brian LaMacchia[SMTP:[email-masked]]
> Sent: 	Wednesday, December 23, 1998 5:58 PM
> To: 	'Luke Koops'
> 	1) It is not clear what a minimally compliant implementation MUST
> support.  It
> 	seems to be:
> 
[ ...MUNCH... ]

> 	In order to be compliant with the protocol, clients just need to
> continue
> 	operating as they already do.
> 
> No, they also need to understand the Full PKI Response message.  A current
> client (that only speaks PKCS#10/7) is not CMC-compliant because it does
> not
> support a standard mechanism for returning error information.
> 
> 	Is there a need to lower the bar for PKIX compliance to this level?
> 
> Obviously, the long-term goal is to use Full PKI Request and Response
> messages throughout.
<Luke>I would not ascribe goals to a standard per se, and I do not claim to
know what the goals of the authors are.

<Luke>It seems to me that this protocol will promote the status quo by
embodying it within a standard.

>   However, CMC also has a goal of supporting
> industry-standard PKCS#10/7 as a subset of the protocol, so that current
> clients and servers can also participate in the CMC world.
<Luke>Current certificate clients could participate in the CMC world with
minimal modifications (support for full response).  A certificate server
could also participate in the CMC world with minimal modifications as well
(issue full response).  But, such a server would not be CMC compliant.  The
standard has many more MUST clauses for a compliant server than it does for
a compliant client.  Your statement illustrates the confusion that will
arise when vendors tout their product as "conforming with", "interoperating
with", "complying to", or "supporting" the PKIX-CMC protocol.  It seems
likely that servers will be written to support minimally compliant clients.

> 	PKIX-CMC needs to clearly state what MUST be supported by a
> minimally
> 	compliant implementation of the client and server.
> 
> Agreed; I will suggest text to the authors for a Conformance section
> (following the table at the top of this mail).
> 
> 	2) There is duplicate information in CRMF and CMC messages.  
[ ...MUNCH... ]
> This comment is similar to the one Carlisle raised.  The intent is that
> controls should appear in the CMC control section, and not in individual
> request bodies.
<Luke>If the intent is not specified in the standard, then other behaviour
should be anticipated and addressed by the standard.
>   Putting the controls in CMC allows individual controls to
> reference/apply to multiple request bodies.  It also puts all the
> processing
> information up front, which facilitates one-pass processing.
> 
> 	3) The regInfo and respInfo controls are 'too open'.  The result is
> that a CA
> 	or RA might not be able to interoperate with two different clients
> which use
> 	regInfo differently.  A bit pattern could be a valid message from
> both types
> 	of clients, but with different semantics.  It might not be possible
> to
> 	specify a parser which can handle both requests.
> 
> 	It would be much better if regInfo and respInfo were not octet
> strings, but
> 	were defined in the following manner.
> 
> 	  ExtraInfo ::= SEQUENCE {
> 	    infoType OBJECT IDENTIFIER,
> 	    info ANY DEFINED BY infoType }
> 
> (I assume you mean responseInfo, not respInfo...)
> 
> I don't see the need to extend the definition of regInfo or responseInfo
> into a SEQUENCE of OID/ANY as you suggest.  If client and server choose to
> define particular semantics for their specific information, and there's an
> OID tagging a structure with those semantics, then that information can be
> passed at top-level as just another CMC control attribute.  It is expected
> that clients and servers that choose to define additional information
> specific to their agreements will pass this information through additional
> control attributes; there's no reason to bury it down inside a
> regInfo/responseInfo/ExtraInfo structure.
> 
> (The regInfo and responseInfo controls themselves were defined for clients
> and servers that have agreed on the semantics of that OCTET STRING through
> some out-of-band mechanism.  For example, in a Web-based enrollment
> scenario
> the server could construct the regInfo using form field values & script.) 
<Luke>This creates the possibility that it would be impossible for a server
to interoperate with the clients from several vendors that use these
controls.  My original statement remains unanswered.

[ ...MUNCH... ]

> ======================================================================
> 	Other observations (collected from other readers here):
> 
[ ...MUNCH... ]

> 	   - it is not possible to securely send the CA root key in the
> response
> 	message.  This might be a serious limitation in some environments.
> 
> What do you mean by "securely send the CA root key"?  Please expand on
> this
> remark.
<Luke>During initialization, a one time password could be used for _mutual_
authentication of the client and the server.  Then the client could rely on
the server to advise it of trusted root keys which would be used for
verifying certificates.

<Luke>In some environments this might be a preferable way to seed the client
with trusted root keys.  Rather than have the software vendor decide which
root keys are trusted, the end user would choose the trust network(s) in
which she will participate.  After making this choice, the user gets an i.d.
and a one time password.  This is all that is required to bootstrap the
client into full participation.

> Hope this answers your questions,
> 
> 					--Brian LaMacchia
> 					  [email-masked]
>