RT RT/krbdev.mit.edu: Ticket #7071 PKINIT trusted_ca encoding issues Signed in as guest.
[Logout]

[Home] [Search] [Configuration]

[Display] [History] [Basics] [Dates] [People] [Links] [Jumbo]

 
 

 The Basics  
Id
7071
Status
open
Worked
0 min
Priority
0/0
Queue
krb5
 

 Keyword Selections  
Component
Tags
Version_reported
Version_Fixed
Target_Version
 

 Relationships  
Depends on:
Depended on by:
Parents:
Children:

Refers to:
Referred to by:
 
 Dates  
Created: Fri Jan 13 09:28:59 2012
Starts: Not set
Started: Not set
Last Contact: Not set
Due: Not set
Updated: Sat Feb 11 00:33:34 2012 by ghudson
 

 People  
Owner
 Nobody
Requestors
 ghudson@mit.edu
Cc
 
AdminCc
 
 

 More about Greg Hudson  
Comments about this user:
No comment entered about this user
This user's 25 highest priority tickets:
 

History   Display mode: [Brief headers] [Full headers]
      Fri Jan 13 09:28:59 2012  ghudson - Ticket created    
     
Subject: PKINIT trusted_ca encoding issues

draft-ietf-cat-kerberos-pk-init-09 defines TrustedCA as:

TrustedCas ::= CHOICE {
    principalName         [0] KerberosName,
    caName                [1] Name
    issuerAndSerial       [2] IssuerAndSerialNumber OPTIONAL
}

(OPTIONAL is not syntactically valid ASN.1 within a CHOICE, so let's
ignore that.)  Per this spec, each alternative should consist of an
explicit context-specific tag followed by the encoding of the specified
object.

Our encoder for this type generates a primitive context tag for all
three alternatives, as if they were wrapped in IMPLICIT OCTET STRING.
Also, for the principalName alternative, it encodes an RFC 4120
PrincipalName instead of a KerberosName as defined by PKINIT (as a
sequence containing a [0] Realm and a [1] PrincipalName).

Our decoder for this type does not care whether the context tags are
primitive or constructed.  It expects a KerberosName for the
principalName alternative, which matches the spec but not the encoder.
It grabs whatever is inside the context-specific tag for the other two
alternatives, so should correctly process either a spec-compliant or
encoder-generated caName or issuerAndSerial.

For reference, Heimdal defines its version of the type as:

TrustedCA-Win2k ::= CHOICE {
    caName                 [1] heim_any,
    isuerAndSerial         [2] IssuerAndSerialNumber
}

which presumably results in the use of constructed context tags.  Note
the absence of a principalName alternative.

The purpose of our draft9 code is to interoperate with Windows 2000, not
to faithfully implement the draft9 spec, so we probably don't want to
change anything without interop testing.


Download (untitled) 1.6k
      Sat Feb 11 00:33:34 2012  ghudson - Comments added    
     
As noted in issue #7062, the PKINIT client code never encodes a TrustedCas
value as part of a draft9 PA-PK-AS-REQ.  So making changes to the encoder
should not affect interop.

The PKINIT server code does potentially decode a TrustedCas value when
decoding a draft9 PA-PK-AS-REQ (if Win2k clients ever send them).
However, it does nothing with this field during processing.


Download (untitled) 378b