Subject: RE: PKINIT open issues

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Tue, 1 Jun 2004 02:03:46 -0700

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.

In addition, this draft references RFC 2630, instead of its successor
RFC 3369, was this intentional? The OCSP extension in the following
draft looks interesting to me:
 http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc3369bis-04.txt

Larry
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Tuesday, May 11, 2004 3:31 PM
To: D. R. Evans
Cc: [email-masked]
Subject: Re: PKINIT open issues

On Tue, May 11, 2004 at 04:10:57PM -0600, D. R. Evans wrote:
> However, re-reading your posting, I'm not completely certain where you

> are intending that there might be a line that could be drawn.

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, so I would
assume a consistent encoding, but PKINIT uses OCTET STRING holes in
Kerberos V, so technically PKINIT could use BER consistently just as
well as DER.

Of course, since Kerberos implementors already use DER I would think
that DER should be preferred, but, then, if existing PKI toolkits fail
to support DER, then BER may be preferred.

> So if you could describe an algorithm for determining which entities 
> could be allowed to be BER encoded I could (possibly, albeit unlikely)

> be persuaded that BER encoding should be permitted for some objects if

> someone really wants to do that.

I don't know if this is a hard and fast rule off the top of my head, but
I'd be surprised if it weren't:

    Within a single encoded value of some ASN.1 type, a single encoding
    type should be used throughout from the root of the value, but this
    should not constrain the encoding of values stuffed into OCTET/BIT
    STRING and other such holes (e.g., IOS holes and the old "ANY") in
    the first value's type.

Nico
--

---

From: Love <[email-masked]>
Date: Tue, 01 Jun 2004 12:46:18 +0200

> 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: Sam Hartman <[email-masked]>
Date: Wed, 02 Jun 2004 14:08:46 -0400

>>>>> "Love" == Love  <[email-masked]> writes:

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

    >>> 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.

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

I agree with Love and Larry that the CMS objects should be
octet-strings.  I do not know how I feel about inevitable comments
about delay of the spec or interoperability.  I do know that we have
two of the three vendors who have come forward on this list claiming
that the feature is important to use existing CMS libraries.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 2 Jun 2004 14:48:33 -0500

> that the feature is important to use existing CMS libraries.

I am in favor of the wrap-CMS-objects-in-OCTET-STRING proposal as well.