Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

[Steven Legg <steven.legg@xxxxxxxxxxx>]

Tom,

Tom Yu wrote:
> > > > > > "Peter" == Peter Sylvester <Peter.Sylvester@xxxxxxxxxx> writes:
>
>
> Peter> Steven Legg wrote:
>
>
> > > Love, et al,
> > >
> > > Love Hörnquist Åstrand wrote:
> > >
> > >
> > > > Lets take another example:
> > > >
> > > > PA-PK-AS-REQ ::= SEQUENCE {
> > > > signedAuthPack          [0] IMPLICIT OCTET STRING,
> > > > -- Contains a CMS type ContentInfo encoded
> > > > -- according to [RFC3852].
> > > > -- The contentType field of the type ContentInfo
> > > > -- is id-signedData (1.2.840.113549.1.7.2),
> > > > -- and the content field is a SignedData.
> > > >
> > > > With you syntax this should be
> > > >
> > > > signedAuthPack IMPLICIT OCTET STRING OPTIONAL CONTAINING ContentInfo
> > > >
> > > > Now, ContentInfo in a CMS type, and is allowed to be encoded in BER.
> > > > Kerberos datatypes uses DER.
> > > >
> > > > How is that expressed in a formal way ?
> > >
> > >
> > > signedAuthPack IMPLICIT OCTET STRING
>
>
> "IMPLICIT" only goes after a tag, so the above should contain something
> like "[0] IMPLICIT"

Quite right. I was focussed on the constraint and didn't notice the tag
had been dropped.

or drop the IMPLICIT completely.  Dropping the
> context-specific tag would cause a change in wire encoding from
> pkinit-29.
>
>
> > > (CONTAINING ContentInfo
> > > ENCODED BY {joint-iso-itu-t asn(1) ber-derived(2)
> > > distinguished-encoding(1)})
> > > OPTIONAL
> > >
> > > The OID after the "ENCODED BY" is the OID that identifies DER.
>
>
> Except here, we are using a CMS message, which is permitted to be
> encoded in BER, and pkinit requires DER, so you really want something
> like
>
> PA-PK-AS-REQ ::= SEQUENCE {
>     signedAuthPack [0] IMPLICIT OCTET STRING
>         (CONTAINING ContentInfo ENCODED BY {
>             joint-iso-itu-t asn1 (1) basic-encoding (1)
>         })
> }

I'm not an expert on this but it would seem that as far as pkinit is
concerned, the encoding of a ContentInfo value contained in the
signedAuthPack component of a PA-PK-AS-REQ value is always a DER
encoding. It doesn't matter what encoding rules CMS uses to encode
values of ContentInfo, and the constraint has no effect whatsoever
on encodings of ContentInfo values outside the signedAuthPack component.

> You'll need to normatively reference X.682, because the "CONTAINING"
> constraint isn't in X.680.

Yes.

> > > > Just saying IMPORT and CONTANING and expect the right thing to
> > > > happen when
> > > > given to a compiler seems very naive.
> > >
> > >
> > > There's a better chance that the compiler can do something useful than if
> > > the requirements are expressed informally as a comment.
> > >
> > > Regards,
> > > Steven
> > >
> > >
> > > > Love
>
>
> What one can expect from the compiler depends on what sort of compiler
> one is using.  The open-source ASN.1 toolkits with acceptable license
> conditions often omit much of the functionality of the full ASN.1
> standard.

And they always will if ASN.1 specifications always pander to the lowest
common denominator. Contents constraints are a nudge in the right direction.

Regards,
Steven

> ---Tom