Subject: PKINIT: various [resend due to message overflow]

From: Brian Tung <[email-masked]>
Date: Wed, 28 Feb 2001 10:35:17 -0800

[This message was previously sent and bounced because it was >40k in
length.  Sorry about the delay--I didn't realize.]

This message is in response to comments by Ken Raeburn, Sam Hartman,
and Doug Engert.  Some of the draft authors--Matt Hur, Sasha Medvinsky,
and myself--conferred for some time in the construction of this reply.

Ken Raeburn wrote:
> 1) I'd like to see a few more examples of name handling (principal
>    names, realm names, transited-realm encoding).  I think I
>    kind of understand what's being described, but not being
>    an expert on some of the PKI, confirmation wouldn't hurt.

Doug Engert wrote:
> [DEE Don't think this is a problem we can live without more
> examples.]

I agree.

KR:
> 2) Some of us are working on revising section 6 of RFC1510bis to be a
>    bit more structured, to define a "profile" for a cryptosystem
>    definition and rewrite the existing ones to fit that profile.
>    IMNSHO, it would be a big win if PKINIT used this framework.
> 
>    For example, rather than "truncate to n bits and maybe
>    fix parity", wouldn't "use the encryption algorithm's key generation
>    function X" make it cleaner to extend to new cryptosystems where a
>    random string of bits might not be a valid key (whether because of
>    weak key checks, or use of prime numbers, or whatever)?  If
>    PKINIT can't fit into the framework we set up for cryptosystems,
>    perhaps other preauth schemes will have problems too; in that case,
>    we need to adjust the framework.
>
>    Yes, I know it's hard to write to a spec that hasn't been seen yet.
>    I'm the editor for these changes, and hope to have something out
>    for comments by the end of this week or early next week.

DE:
> [DEE This should not stop the working group last call on
> this. In the long run, may want to go back to the PKINIT to have
> it use the framework, but this should not stop the current version.]

If and when RFC 1510bis specifies uniform key generation functions for
various cryptosystems, and doing so makes it appropriate to change
PKINIT to reflect this change, we'll revisit this segment of the spec
(3.1.1) at that time.

KR:
> 3) As I understood it, PKINIT is supposedly dependent on 1510bis.  If
>    that's the case, the references to RFC 1510 should be changed to
>    whatever 1510bis will be.

DE:
> [DEE I listed that as the one change to be made in the call.
> So this is not a problem, and will be fixed.]

So noted.

KR:
> 4) At line 624, "mapping mapping" is probably supposed to be just
>    "mapping".

Done.

KR:
> 5) Around line 643, the handling of email addresses mentions the
>    possibility of doing name canonicalization.  Does this mean that
>    (if the KDC chooses to handle the S/MIME case through
>    canonicalization) the email address should be treated as
>    any other SMTP-type principal name for which canonicalization
>    is requested?  If it's not canonicalizing as the KDC would for
>    a client specifying the same name and type (which type PKINIT should
>    specify), then the spec shouldn't use "canonicalization" but
>    should instead talk about some sort of database lookup that
>    doesn't need to be tied to name canonicalization.

The text in question has been changed to remove the word
"canonicalization" and to indicate that the mapping depends on local
policy.  It may, for example, be done by database lookup (and this
too is given as an example in the text).

KR:
> 6) Section 3.1: It might be worth noting that PrincipalName in
>    Kerberos will be using UTF-8 strings (are we going with the
>    "KerberosString" type?) even though the ASN.1 language says
>    GeneralString, so converting to a CertPrincipalName will
>    require no translation of the strings.
>
>    I don't know about the constraints on ASN.1 use in the PK specs
>    or implementations, but if it isn't strict, maybe the Kerberos
>    types could just be used directly, letting an implementation
>    simply copy objects rather than re-encoding them.  A strict
>    implementation already won't work for Kerberos, though of course
>    using two separate implementations, one for PK and one for Kerberos,
>    might yield a situation where Kerberos is implemented with lax ASN.1
>    conformance and the PK bits are strict.

In conversation with Russ Housley, he indicated that PKIX had no
party line with respect to requiring UTF8 in certificates, and in
fact asserted that multiple encodings should be supported.  For
that reason, we are discarding use of the CertPrincipalName structure
entirely.  This simplifies the spec and it simplifies processing.

Sam Hartman wrote:
> 1) There are normative references to pkcross and pktapp in the
>    introduction.  These documents have not been reviewed and it is
>    not clear we have committed to these directions; perhaps these
>    documents should backreference to pkinit instead.

We will change this to refer to PKCROSS and PKTAPP as efforts (in
the sense of examples of applications) rather than as I-Ds.

SH:
> 2) Around line 218, the document uses the word shall; I really think
>    it means MUST.  However, I'm also concerned with the text.  It
>    requires the KDC to use a specific name type for x500 principals
>    and requires the client to do the same.  So far, we have not
>    actually required the name type be used, or at least we 
>    have always allowed the unknown name type to be used and required 
>    that it work.
> 
>    I do not agree with this change, and certainly think more effort
>    should be put into thinking through the implications of this
>    change.

We're clarifying the text to indicate that you MUST support this
mapping, but that you may use other name types.  Note that the name
type in question is only required when the encoding specified in the
section is used.

SH:
> 3) In the same paragraph, it describes how to set the name string for
>    the x500 principal.  Don't we already do that in revisions?  Why
>    does pkinit need to either do something different that standard
>    practice for x500 principals, or if it is specifying the same
>    thing, specify by value rather than reference?  When standards do
>    this, I as an implementer must check to make sure the standard
>    specifies the same thing as the referenced standard before I can
>    reuse libraries.  This is very annoying and when the standards
>    needlessly conflict, damaging.

At the present time, RFC 1510 revisions does not give a complete
specification of how to encode X.500 names.  It provides an example
(Section 7.1) which is not sufficient to flesh out a standard for
interoperability.  PKINIT achieves this by adhering to a known
standard--viz, RFC 2253.  

SH:
> 4) Around line 260, the text refers to principals given as
>    user+instance.  I don't think that RFC1510 defines instance as
>    related to users, nor does it   really use instance as a
>    well-defined term.  I really think you want to define the matching
>    rules in terms of components, without treating components as
>    distinguished.

This has been changed to refer to "client principal name" instead of
"user plus instance."

SH:
> 5) Still in the same constraint matching, isn't  a x500 realm name
>    likely to  be of type other since the encoding  specified earlier
>    in the document  requires it?  Won't this mean we always get
>    byte-for-byte matches even for x500 realms?

Agreed, this is deadwood.  We'll delete option 2b.

SH:
> 6)  I agree with Ken that 3.1.1 should hold off until we get 
>     section 6 for revisions.  The current text is unfortunately DES specific.

Read the text carefully; it's not DES-specific.  DES is only used
as an example.

SH:
> 7) In the header to 3.2, the text states that certs are not needed if
>    the case where the KDC maintains public keys.  Yet on line 448, the
>    text requires the client to include at least a signature cert.
>    Reconcile please.

We'll remove the line "However...a signature certificate."

SH:
> 9) In 3.2.2, why do we prefer a KDC cert issued by the client's CA to
>    one issued by one of the client's trusted certifiers?

OK.  We'll remove option 2.

SH:
> 10) Around line 693, please reference some authority whose
>     implementation you follow.  Including explanatory text is
>     reasonable, but pkinit should not be authoritative for  DH.
>     Mentioning DES keys specifically seems bad.

We are not specifying how DH is used worldwide; we are specifying how
it is used within PKINIT.  We will change 3 and 4 to 2a and 2b,
referencing them only as examples.

SH:
> 11) Around line 756  the text specifies that RSA  keys must be used
>     for KeyTransRecipientInfo .  This seems out of place for pkinit.
>     Pkinit should require RSA support, but should not limit what
>     encryption can be used.

We'll drop RSA.

SH:
> 12) On line 801 indicate that you are taking encryptionkey from
>     revissions;  you do not define it yourself.

We'll add a comment that this comes from RFC 1510bis.

SH:
> 13) On line 811, the document flow must be improved.  We have just
>     concluded text on the non-DH case, and the text jumps to dealing
>     with transited realms with no section break or other marker that
>     people skipping the non-DH case should start paying attention
>     again.  I could even make a weak argument that those only looking
>     at DH don't need to implement that section of text based on the
>     flow.

We'll insert subsection 3.2.2.1 for the transited field, and
subsection 3.2.2.2 for the KerberosNames in certificates, and section
3.2.3 for the client extraction of the reply.  3.2.3 becomes 3.2.4.

SH:
> 14) The introduction claims that the KDC can store private keys, but
>     the mechanisms to do that appear to have disappeared.  This is
>     probably good, but the references to thes mechanisms should be
>     removed.

If Sam is referring to the phrase "secret key" on or around line 95,
that phrase has historically referred not to private keys, but to
symmetric keys (shared secrets).  In order to avoid confusion, we
are changing that to "symmetric key."

The draft copy below reflects the changes described in the response
above.  This is what will be sent to the I-D server.

Brian Tung <[email-masked]>

*****

[draft snipped for brevity, will be sent in next message]