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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sam Hartman-5
>>>>> "Tom" == Tom Gindin <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Love Hörnquist Åstrand

Peter Sylvester <[hidden email]> 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


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Love Hörnquist Åstrand
In reply to this post by Sam Hartman-5

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


attachment0 (487 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Peter Sylvester-3
In reply to this post by Love Hörnquist Åstrand
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:
>
>> Peter Sylvester <[hidden email]> writes:
>>
>>
>>> The first one can be replaced by
>>>
>>>        subjectName            [0] IMPLICIT OCTET STRING OPTIONAL
>>> CONTAINING Name
>>
>
> The correct syntax here is:
>
>          subjectName   [0] IMPLICIT OCTET STRING (CONTAINING Name)
> OPTIONAL
>
>>
>>
>> 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
>                   (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.
>
>>
>> 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
>>
>
>
>

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


smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Tom Yu
>>>>> "Peter" == Peter Sylvester <[hidden email]> 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" 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)
        })
}

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

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

---Tom