Subject: RE: Love's issue #4; was: Re: PKINIT open issues

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sat, 29 May 2004 16:27:01 -0700

Doug wrote:

> Note that the field for the encryption cert in PA-PK-AS-REQ - proposed
to be moved inside signedAuthPack - 
> is not the whole cert, it's just issuer&serial number. The cert itself
is inside the SignedData's > 
> CertificateSet...

How does the KDC find out if an adversary has changed the encryption
certificate and the issuer&searial# field? If it is already protected,
the draft should be clear about how this is done.

Thanks,

Larry

-----Original Message-----
From: Doug Mitchell [mailto:[email-masked]] 
Sent: Saturday, May 29, 2004 3:22 PM
To: Sam Hartman
Cc: Love; [email-masked]; Doug Mitchell; Liqiang(Larry) Zhu
Subject: Re: Love's issue #4; was: Re: PKINIT open issues

On May 29, 2004, at 1:13 PM, Sam Hartman wrote:

> Does the document currently say that you use the signing cert for 
> encryption anywhere?

As was shown in this list recently, IETF draft 19 doesn't really say -
at all - HOW public key encryption is done. Love's proposed addenda
clarifies and says you encrypt with one or the other (signing, or
encryption cert).

>  Are you actually even required to include a copy of the signing cert?

Yes. From 3.2.1:

     The ContentInfo in the signedAuthPack is filled out as follows:

     ...snip...

     4.  The certificates field MUST contain at least a signature
         verification certificate chain that the KDC can use to
         verify the signature over the AuthPack.  Additionally, the
         client MAY insert an encryption certificate chain, if
         (for example) the client is not using ephemeral-ephemeral
         Diffie-Hellman.

Note that the field for the encryption cert in PA-PK-AS-REQ - proposed
to be moved inside signedAuthPack - is not the whole cert, it's just
issuer&serial number. The cert itself is inside the SignedData's
CertificateSet...

--dpm