Subject: pkinit-21

From: Love <[email-masked]>
Date: Sat, 13 Nov 2004 18:56:39 +0100

Just glanced over the pk-init-21 document and these are the first things I
found

Love

L21.1 Why isn't Name in TrustedCA/TrustedCertifiers wrapped with OCTET STRING.
   Same goes for CertificateIndex.

|    1.  The eContent field contains data of type AuthPack.  It MUST
|        contain the pkAuthenticator, and MAY also contain the
|        client's Diffie-Hellman public value (clientPublicValue).

L21.2 How can it not contain the pkAuthenticator ? Its non-OPTIONAL.
L21.3 Missing from 1: "supportedCMSTypes is filled with the
  algorithmidentifier that the client support with the most preferred
  one first."

L21.4 Its unfortunely that there is a trustedCertifiers and a
  TrustedCertifiers. Change the later to KdcTrustedCertifiers.

|    3.  The signerInfos field MUST contain the signature over the
|        AuthPack.

L21.5 This pulls signerInfos out of the thin air. signerInfos is part of the
  CMS structure, why do we care about that. If anything, it should be
  something like this:

    3.  The ....

L21.6 At this point I notice that the text is just completely broken, there
  isn't any consistency to this text (3.2.1.  Client Request).

  What should we do about this, should I just rewrite the should section ?
  It possible to figure out what the author mean, but its still wrong.

|The ContentInfo in the signedAuthPack is filled out as follows:
|
|
|   1.  The eContent field contains data of type AuthPack.  It MUST
|       contain the pkAuthenticator, and MAY also contain the
|       client's Diffie-Hellman public value (clientPublicValue).

the ContentInfo doesn't have a eContent type, it has a contentType and
a content. SignedData on the other hand have a EncapsulatedContentInfo
that contains a eContent.

This goes on like this for the whole section.

|  6.  Expiration Date
|
|     This draft expires January 25, 2004.

L21.7 This draft is already expired.

L21.8 So the issue with encryption certificate wasn't as I remember the
  problem what the policy/publickeytype doesn't allow encryption,
  rather is was the idea that using same rsa key for encryption and
  signing might be a bad idea.

|    PA-PK-AS-REP ::= CHOICE {
|        dhSignedData            [0] IMPLICIT WrapContentInfo,
|                                    -- Type is SignedData.
|                                    -- Content is KDCDHKeyInfo
|                                    -- (defined below).
|        encKeyPack              [1] IMPLICIT WrapContentInfo,
|                                    -- Type is EnvelopedData.
|                                    -- Content is SignedData over
|                                    -- ReplyKeyPack (defined below).
|        ...
|    }

L21.9 This comment is confusing, it's very unclear in what order the
  EnvelopedData vs SignedData is applied, the text below somewhat
  clears that out, but the comment is just confusing.

|    6.  The recipientInfos field is a SET which MUST contain exactly
|        one member of type KeyTransRecipientInfo.  The encryptedKey
|        for this member contains the temporary key which is
|        encrypted using the client's public key.

L21.10 this is described how to do by CMS, why is this here ?

    6.  The enveloped data MUST contain one KeyTransRecipientInfo
	that is targeted to the client's certificate.

L21.11 I think the client MUST NOT send the CMS kerberos encryption
    types if it only send the new TDB pa-type number but only use
    the new supportedCMSTypes.

| [2] R. Housley. Cryptographic Message Syntax. April 1999.  Request
| For Comments 2630.

L21.12 RFC2630 is obsoleted by RFC3369, RFC3370.

| KDC-REQ-BODY to indicate which CMS [2] algorithms it supports.

L21.13 RFC3370 specifies the algorithms CMS uses, also RFC3565 refernced
   since that is the spec for use of the AES Encryption Algorithm in CMS.
   So given this, the [2] needs to split in two, CMS as protocol and CMS
   algorithms.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 13 Nov 2004 15:52:14 -0500

Love, I'd recommend reading draft-housley-cms-fw-wrap for an example
of how much detail at least one CMS person thinks is necessary when
describing how to use their encodings.  Particularly look at section 2
and 3.

I picked this draft because I recently reviewed it.

--Sam

---

From: Love <[email-masked]>
Date: Sat, 13 Nov 2004 22:36:05 +0100

> I picked this draft because I recently reviewed it.

Sam,

I'll read over the draft later, just browsed over it.

I don't really care if the pk-init get more verbose, it just need to be
understandable, right now it isn't.

Compare the description for pk-init client encode the request with section
two of of cms-fw-wrap. Just as a description waht is missing

   "The Cryptographic Message Syntax (CMS) is used to protect a firmware
   package, which is treated as an opaque binary object.  A digital
   signature is used to protect the firmware package from undetected
   modification and provide data origin authentication.  Encryption is
   optionally used to protect the firmware package from disclosure, and
   compression is optionally used to reduce the size of the protected
   firmware package. "

and the continutation is the important part:

                     "The CMS ContentInfo content type MUST always be
   present, and it MUST encapsulate the CMS SignedData content type.  If
   the firmware package is encrypted, then the CMS SignedData content
   type MUST encapsulate the CMS EncryptedData content type."

The pk-init document never spells something like this out, you have to
guess it from comments and hints from the text by reading the structure
elemented that is used.

Love

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 16 Nov 2004 11:37:14 -0500

> L21.2 How can it not contain the pkAuthenticator ? Its non-OPTIONAL.

So, you are saying that the "MUST contain the pkAuthenticator" should be removed
from the text because it is redundant?  If so, then the whole 2nd sentence
is redundant because the fact that the clientPublicValue is optional is
also spelled out in the ASN.1 definition.

>   algorithmidentifier that the client support with the most preferred

Isn't that also already explained in the ASN.1 definition for AuthPack?

>   It possible to figure out what the author mean, but its still wrong.

I agree that 3.2.1 is a bit hard to follow, but this is what I got from it.

SignedAuthPack = BER encoding of ContentInfo
ContentInfo {
	- ContentType = SignedData
	- content = SignedData {
		- CMSVersion
		- digestAlgorithmIdentifiers
		- EncapsulatedContentInfo
			- eContentType = OID 1.3.6.1.5.2.3.1
			- eContent = OCTET STRING
				- AuthPack
		- CertificateSet [MUST contain a signature verification chain to be used by KDC]
		- CertificateRevocationLists [OPTIONAL]
		- SignerInfos [ SET OF SignerInfo ]
			- CMSVersion
			- SignerIdentifier
			- DigestAlgorithmIdentifier
			- SignedAttributes [OPTIONAL]
			- SignatureAlgorithmIdentifer
			- SignatureValue [ signature over AuthPack used in eContent above ]
			- UnsignedAttributes [OPTIONAL]
	}
}

It seems that the definition for "signedAuthPack" in 3.2.1 is confusing in how it
uses "Type" and "Content" as defined fields.  Would something like this help to clarify
that the AuthPack is actually in the encapsulatedContentInfo field from the
SignedData ?

PA-PK-AS-REQ : := SEQUENCE {
	signedAuthPack		[0] IMPLICIT WrapContentInfo,
					-- ContentType is SignedData
					-- content is SignedData where
					-- eContent of encapContentInfo contains AuthPack
	trustedCertifiers	[1] SEQUENCE of TrustedCA [OPTIONAL]
	kdcCert			[2]  IMPLICIT WrapIssuerAndSerial [OPTIONAL]
}

-Wyllys Ingersoll
   Sun Microsystems