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

From: Sam Hartman <[email-masked]>
Date: Tue, 01 Nov 2005 09:27:12 -0500

>>>>> "Tom" == Tom Gindin <[email-masked]> writes:

    Tom>         If it isn't too late to fix this without breaking
    Tom> lots of implementations, the ASN.1 in this specification is
    Tom> over-tagged.  In section 3.2.1, all three of the tags in
    Tom> PA-PK-AS-REQ are unnecessary, and the one on signedAuthPack
    Tom> is actually slightly harmful.  None of the tags in
    Tom> PKAuthenticator do any good either.  The OCTET STRING
    Tom> wrappings for subjectName and issuerAndSerialNumber are not
    Tom> really appropriate, and subjectName doesn't need a tag.  Even
    Tom> in AuthPack, pkAuthenticator and clientDHNonce don't need
    Tom> tags.  Similarly, in 3.2.3, there is no reason for any of the
    Tom> tags in PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo.  The tags
    Tom> in ReplyKeyPack in 3.2.3.2 also seem unnecessary.

The kerberos working group has a rather different philosophy on ASN.1
than the PKIX community.  We've attempted to draw strong boundaries
around structures to the extent that we can: kerberos structures use
our conventions; PKIX structures use yours.

The short answer is that tagging issues have been discussed
extensively across all our ASN.1 usage.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 02 Nov 2005 20:53:44 +0100

Peter Sylvester <[email-masked]> writes:

> The first one can be replaced by
>
>         subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

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 ?

Just saying IMPORT and CONTANING and expect the right thing to happen when
given to a compiler seems very naive.

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 02 Nov 2005 21:00:56 +0100

Peter,

> Tagging is a matter of ket's say "taste", in fact, it is a matter of
> implementation
> experience. ASN.1 after many years has come with AUTOMATIC tags
> allowing automatically unambiguous and non-excessive explicit tagging.

The excessive amount of tagging seems like minor nit, its bloaty, sure, its
like rest of the Kerberos protocol.

> Wrapping: Strong boundaries would make sense if you don't have to
> cross them
>
> Interoperability note: Some implementations may not be able to decode
>    wrapped CMS objects encoded with BER but not DER; specifically, they
>    may not be able to decode infinite length encodings. 
>
>
>
> something that seems to be necessary according to the previous citation.
>
> As soon as you have the data structure that you wrap,
> you can also encode them in DER. I doubt that you just have the
> octet string contents only available as blobs.

The CMS implemtetion might use another asn1-package then then Kerberos
implemetation, I think today that this is the common case. You call CMS
package, get back blob, and you have no clue about the encoding it used
used.

Love

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 03 Nov 2005 10:37:49 +0100

Hi,

I stand corrected (for the syntax). For the rest, I am not sure whether
I could have given an explanation as precisely as Steve. :-)

Peter

Steven Legg wrote:

>
>
> Love, et al,
>
> Love Hörnquist Åstrand wrote:
>
> The correct syntax here is:
>
>          subjectName   [0] IMPLICIT OCTET STRING (CONTAINING Name) 
> OPTIONAL
>
>>
>>
> signedAuthPack IMPLICIT OCTET STRING
>                   (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.
>
>>
> 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
>>
>
>
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: Tom Yu <[email-masked]>
Date: Sun, 06 Nov 2005 01:01:06 -0500

>>>>> "Peter" == Peter Sylvester <[email-masked]> writes:

>> signedAuthPack IMPLICIT OCTET STRING

"IMPLICIT" only goes after a tag, so the above should contain something
like "[0] IMPLICIT" or drop the IMPLICIT completely.  Dropping the
context-specific tag would cause a change in wire encoding from
pkinit-29.

>> 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)
        })
}

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

>> the requirements are expressed informally as a comment.

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.

---Tom

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 06 Nov 2005 16:14:09 +0100

I think we may have a different opinion of what could be maintenance.
Feel free to explain.

Anyway, You can do exactly what AUTOMATIC does with concrete tags.

The message was not necessarily to promote AUTOMATIC, but a question
why there is a different tagging regime involved which is not totally 
respected
because OCTET STRINGS are IMPLICIT tagged when the contain other
syntaxes.

Russ Housley wrote:

>
> I find AUTOMATIC TAGS to be more difficult later down the line when 
> one is doing maintenance. In my opinion, it hides too much.
>
> Russ
>
> At 09:10 AM 11/3/2005, Olivier Dubuisson wrote:
>
>> Tom Gindin wrote:
>>
>>> If it isn't too late to fix this without breaking lots of 
>>> implementations, the ASN.1 in this specification is over-tagged. In 
>>> section 3.2.1, all three of the tags in PA-PK-AS-REQ are 
>>> unnecessary, and the one on signedAuthPack is actually slightly 
>>> harmful. None of the tags in PKAuthenticator do any good either. The 
>>> OCTET STRING wrappings for subjectName and issuerAndSerialNumber are 
>>> not really appropriate, and subjectName doesn't need a tag. Even in 
>>> AuthPack, pkAuthenticator and clientDHNonce don't need tags.
>>> Similarly, in 3.2.3, there is no reason for any of the tags in 
>>> PA-PK-AS-REP, DHRepInfo, or KDCDHKeyInfo. The tags in ReplyKeyPack 
>>> in 3.2.3.2 also seem unnecessary.
>>
>>
>> The easiest thing would be to put "AUTOMATIC TAGS" in the module 
>> header (instead of "EXPLICIT TAGS") and not bother with tags, for 
>> "AUTOMATIC TAGS" would tag where necessary. But I understand from 
>> another response that the Kerberos team doesn't want to deviate from 
>> their historical choice...
>> -- 
>> Olivier DUBUISSON
>> France Telecom
>> Recherche & Developpement
>> R&D/MAPS/AMS - 22307 Lannion Cedex - France
>> t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/
>>
>>
>
>
>

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 06 Nov 2005 16:14:17 +0100

BTW:

Since SNACC is mentioned. There is one application thta uses SNACC, and in
order to decode soem data encapsulated in an OCTET STRING the author
has changed the syntax to something like

[UNIVERSAL 4] IMPLICIT SEQUENCE {data TheType}

and then changed in the generated code the generation/parsing of the 
constructed
bit by hand. If the syntax would not have the addition OCTET STRING 
encapsulation
such a hack wouldn't be necessary.

Steven Legg wrote:

>
> Olivier Dubuisson wrote:
>
>> The right syntax is:
>> subjectName [0] IMPLICIT OCTET STRING(CONTAINING Name) OPTIONAL
>>
>> It would be even better to add an "ENCODED BY oid" after "CONTAINING 
>> Name" with 'oid' being the OID of the binary encoding rules used to 
>> encode 'Name'.
>>
>> But I can already hear some people saying: This is not supported by 
>> Snacc :(
>
>
> Since the constraint does not change the bits on the wire for BER the
> simple retort is: "If your ASN.1 compiler does not support
> CONTAINING constraints then comment them out". The hardship caused to
> users of dumber ASN.1 toolkits is negligible in a case like this.
>
> Regards,
> Steven
>
>