Subject: RE: PKINIT open issues

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 1 Jun 2004 08:32:52 -0700

Love wrote:
> I'm doing that by misuse of ANY. I pointed this problem in minneapolis
> (I think it was there), but it was 
> rejected that it would delay (haha) the pkinit draft.

I do not think it will delay the draft by using OCTET strings. It is a
bit far-stretching by demanding what encodings the CMS libraries can
use. This draft as it is is not implement-able.

I am looking into something as follows:

   KERB-PA-PK-AS-REQ ::= SEQUENCE {
                           
      signed-auth-pack        [0] IMPLICIT OCTET STRING,
                                -- SignedData
      trusted-certifiers      [2] SEQUENCE OF KERB-TRUSTED-CAS OPTIONAL,
                                -- CAs that the client trusts
      kdc-cert                [3] IMPLICIT OCTET STRING OPTIONAL,

    <<< cut >>>
   } 

Larry

-----Original Message-----
From: Love [mailto:[email-masked]] 
Sent: Tuesday, June 01, 2004 3:46 AM
To: Liqiang(Larry) Zhu
Cc: Nicolas Williams; D. R. Evans; [email-masked]
Subject: Re: PKINIT open issues

"Liqiang(Larry) Zhu" <[email-masked]> writes:

>  
> Nicolas Williams wrote:
>
>> IMO, wherever Kerberos V or Kerberos extensions like PKINIT have 
>> OCTET
> STRINGs (or BIT STRINGs even)
>> containing non-Kerberos data then the encoding of their content is
> controlled by the specification of that
>> content, whatever it is.
>> PKINIT does not have any such OCTET STRINGs or BIT STRINGs,
>
> I am trying to catch up on this and I did not see any further thoughts

> on this idea.
>
> I think it is a fine idea to specify the CMS objects as OCTET strings.

> I do not know how, otherwise, one can use existing CMS libraries for 
> the PKINIT messages. This way we can also abstract better the CMS
objects.

I'm doing that by misuse of ANY. I pointed this problem in minneapolis
(I think it was there), but it was rejected that it would delay (haha)
the pkinit draft.

Lets change

PA-PK-AS-REQ ::= SEQUENCE {	-- PAType 14
	signedAuthPack          [0] ContentInfo,
	trustedCertifiers       [1] SEQUENCE OF TrustedCAs OPTIONAL,
	kdcCert                 [2] IssuerAndSerialNumber OPTIONAL,
	encryptionCert          [3] IssuerAndSerialNumber OPTIONAL,
	...
}

to

PA-PK-AS-REQ ::= OCTET STRING -- contains cms signed AuthPack

AuthPack ::= SEQUENCE {
         [old AuthPath fields]
         [old PA-PK-AS-REQ fields, encryptionCert changed to
Certificate] }

Love

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 1 Jun 2004 11:45:34 -0500

> use. This draft as it is is not implement-able.

IIRC at MN we were still trying to minimize or avoid incompatible
changes to PKINIT and this may have seemed like the sort of thing that
could be hacked around.

Now I think we have enough problems with the spec to justify making this
sort of change.

And I note that Love's proposal isn't really backwards incompatible.
Any implementor wishing to interop with old versions that didn't use the
OCTET STRING wrapper as in Love's proposal will be able to use the DER
tag to distinguish between implementations of the old drafts and the
newer draft.

So I 

>       kdc-cert                [3] IMPLICIT OCTET STRING OPTIONAL,

Six of one, half a dozen of the other.  Somewhere in the spec we need
OCTET STRINGs to switch encoding from DER (for Kerberos) to BER (for
CMS); either all (most) of the PKINIT types are encoded as are CMS types
and then are wrapped in an OCTET STRING (Love's proposal) or all CMS
types referenced by PKINIT types are wrapped in an OCTET STRING (Larry's
proposal).

I might prefer Larry's proposal, mostly because it more cleanly
separates PKINIT and CMS, except that PKINIT mostly references CMS
types, so if we follow Larry's proposal PKINIT will end up with lots of
OCTET STRINGs...

Note too that we can use CONTAINING <Type> ENCODED BY <Value> contraints
to reference the CMS types from the PKINIT types, so if we took Larry's
proposal then PA-PK-AS-REQ would look like:

PA-PK-AS-REQ ::= SEQUENCE {
    signed-auth-pack        [0] OCTET STRING CONTAINING
				    SignedData ENCODED BY ber,
    trusted-certifiers      [2] SEQUENCE OF KERB-TRUSTED-CAS OPTIONAL,
    kdc-cert                [3] OCTET STRING CONTAINING
				    IssuerAndSerialNumber
				    ENCODED BY ber OPTIONAL,
    ...
}

Cheers,

Nico
--

---

From: Love <[email-masked]>
Date: Tue, 01 Jun 2004 20:09:07 +0200

> types, so if we follow Larry's proposal PKINIT will end up with lots of

Larrys proposal is wire compatible with the old pk-init-10, so I don't
really mind using that instead. And I would guess its almost wire
compatible with -19.

And in fact, larrys proposal was what I requested in MN, so I don't care at
all is this is choosen instead of mine.

Love