Subject: Re: Pkinit -19 comments: section 3.2.2

From: "D. R. Evans" <[email-masked]>
Date: Tue, 11 May 2004 11:21:58 -0600

Liqiang(Larry) Zhu said the following at 04/12/2004 04:39 PM:-

> 
>>If the name in the request is [special "blank"
>>name], the KDC MAY insert a different name in the reply.
> 
> 
> I think it is easier implementation wise if we introduce a new name type
> "NT-ENTERPRISE-X500-PRINCIPAL". This name type is similar to
> NT-X500-PRINCIPAL (would NT-X500-PRINCIPAL encode the issuer as the
> realm name?), and it will force NC, but otherwise it can be the same as
> NT-X500-PRINCIPAL.
> 
> 

Larry,

1. Are you proposing that it would be mandatory for a PKINIT-enabled KDC 
to support your proposed new name type?

2. It seems to me a bit weird to introduce a new name type in a document 
that merely describes how a particular pre-auth works; those two 
concepts (pre-auth and name type) seem to me like they should not be 
entangled.

   Doc

-- 

-----------------------------------------------------------
Office:  +1 303 494 0394
Mobile: +1 720 839 8462
Fax:    +1 781 240 0527
-----------------------------------------------------------

---

From: "D. R. Evans" <[email-masked]>
Date: Tue, 11 May 2004 11:16:32 -0600

>  > If the KDC does not have its own mapping and there is no Kerberos
> 
>>name present in the certificate, or if the name in the request does
>>not match the name in the certificate (including the realm name), or
>>if there is no name in the request, the KDC MUST return error code
>>KDC_ERR_CLIENT_NAME_MISMATCH.  There is no accompanying e-data
>>for this error.
> 
> 
> Consider something similar to the language used in clarifications
> section 3.1.5:
> 
>       It also verifies that the sname and srealm in the
>       response match those in the request (or are otherwise expected
>       values),
> 
> 

Larry,

I don't understand why you are proposing that this language is 
necessary. The srealm and sname are not part of PKINIT, so why would we 
want to talk about them at all in this document -- particularly if it's 
only to duplicate a requirement that already exists?

   Doc

--