RE: CMC Comments?

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

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:bal@microsoft.com]
Sent: Wednesday, December 23, 1998 5:59 PM
To: 'Luke Koops'
Cc: ietf-pkix@imc.org; 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.