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

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

I think I second Tom Gindin.

Itseems strange to me to have pieces of the specification
as comments of the asn.1.

example:

         subjectName            [0] IMPLICIT OCTET STRING OPTIONAL,
                  -- Contains a PKIX type Name encoded according to
                  -- [RFC3280].
                  -- Identifies the certificate subject by the
                  -- distinguished subject name.
                  -- REQUIRED when there is a distinguished subject
                  -- name present in the certificate.


The first two lines are syntactic specification, it was common
to have such syntactical restrictions until some years ago.
The others don't belong to the syntax at all.

The first one can be replaced by

       subjectName            [0] IMPLICIT OCTET STRING OPTIONAL CONTAINING Name

and an IMPORT that imports Name from an appropiate module. 


I have the feeling that the following sentence doesn't make sense.

  All data structures carried in OCTET
  STRINGs must be encoded according to the rules specified in
  corresponding specifications.

because as far as I remeber the texts, none of the specifications have 
any particular
requirement on the encoding, You can encode everything in XER, can't you?

There are lots of exemples of useless tagging iKDCDHKeyInfo or
PKAuthenticator All base tags are different, and there is only one 
optional field.
Well, that'a a matter of style as well as the global EXPLICIT default.

         nonce                   [1] INTEGER (0..4294967295),
                  -- Contains the nonce in the PKAuthenticator of the
                  -- request if DH keys are NOT reused,
                  -- 0 otherwise.

To me the comment seems to suggest that

	nonce                   INTEGER (1..4294967295) OPTIONAL 


could be more appropriate. But, the nonce in PKAuthenticator says:

         nonce                   [2] INTEGER (0..4294967295),
                  -- Chosen randomly;  This nonce does not need to
                  -- match with the nonce in the KDC-REQ-BODY.

so it can be 0.



This comment doesn't change anything fundamental of the spec.


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.
>
> Tom Gindin
> P.S. - The opinions above are mine, and not necessarily those of my 
> employer.
>
>
>  


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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature