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

From: [email-masked]
Date: Tue, 01 Nov 2005 19:20:32 +0000

Sam what you are looking at is the obvious incompetence in the IETF and ISOC's management to allow for a myriad of incompatible notation schemas... Just another reason why the IETF is a joke.

Todd Glassey
 -------------- Original message ----------------------
From: Sam Hartman <[email-masked]>
> 
> >>>>> "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: [email-masked]
Date: Wed, 2 Nov 2005 15:29:59 +0100

I second Tom and Peter positions.

Since you asked, you got three consistant answers.
It is not appropriate to over tag and over comment in the ASN.1 syntax.

I believe that the A-Ds should make sure the ASN.1 descriptions coming from different WGs have the same look and feel.

In addition:

From the introduction, it is hard to know which kind of private key is needed:

is it a private key for decryption or/and for digitally signing ?

It is also hard to know whether a pure signature algorithm like DSA may be used.

Later on from the next, it seems that the answer is "only the RSA algorithm can be used".

Step 2 as described in section 3, mandates the use of a public key certificate,

but step 1 only mentions that a public key is passed, instead of a public key certificate.

Steps 1 and 2 need to be made consistant.

Please clarify the introduction to these respects.

The syntax of ExternalPrincipalIdentifier (used by trustedCertifiers) is quite odd.

Why is simply a self-signed certificate not allowed ?

Should md5 really be still allowed ?

There should be an early discussion to say when 3a and 3b (from section 3) are needed or "best".

The draft seems to have too many mandatory options to implement.

If I have more time, I will read the draft in more details.

In the mean time, responses to the above questions will be interresting.

Denis

PS. I am puzzled that you answered (as AD ?) instead of the editor(s).

[email-masked] wrote: -----

To: Tom Gindin <[email-masked]>
From: Sam Hartman <[email-masked]>
Sent by: [email-masked]
Date: 01/11/2005 03:27PM
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos

---

From: [email-masked]
Date: Wed, 02 Nov 2005 18:20:19 +0000

Denis - doesnt the idea that the IETF as a whole needs to sign off on ASN.1 Notation in order for their to be any responsibility of any A-D's anywhere to push it seem reasonable to you? Or does PKIX rule the IETF still? 

Todd Glassey

Subject: Re: [Jeffrey Hutzelman] LAST CALL - Public Key Cryptography for Initial Authentication in Kerberos
From: [email-masked]
To: Sam Hartman <[email-masked]>
Cc: Tom Gindin <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Date: Wed, 2 Nov 2005 17:03:36 +0000

In addition:

Denis