Subject: LIPKEY and SPKM-3 support

From: "Ron Hoffman" <[email-masked]>
Date: Thu, 14 Mar 2002 09:53:41 -0500

I'm working on implementing LIPKEY and SPKM-3 as extensions to an
existing GSS-API implementation of the Kerberos mechanism.  The
code base started with MIT Kerberos 1.0 back in 1997 but has
evolved since then (new MIT Kerberos function has been added to
the existing code base instead of re-porting the MIT code).  As a
result, the code base differs significantly from the current MIT code.

I've finished the ASN.1 support and the first gss_init_sec_context for
SPKM-3.  I'm currently working on the first gss_accept_sec_context.
I've run into some implementation questions which I would like to
discuss with other implementors.

The questions so far:

1) How does gss_import_name() construct the target name since the
   initiator does not have access to the target certificate?

   I'm allowing the target name to be a simple name ("John Doe"),
   a service name ("[email-masked]") or a distinguished name
   ("CN=John Doe,O=Sun,C=US").

   If a simple name is specified, it is encoded as a common name in a
   single RDN sequence.  For example, "John Doe" is encoded as
   "CN=John Doe".

   If a service name (service@host) is specified, it is converted to
   "service/host" and encoded as a common name in a single RDN sequence.
   For example, "[email-masked]" is encoded as
"CN=nfs/server.sun.com".

   A distinguished name is used as-is.

2) How does the acceptor validate the target name?

   Since the initiator may not know the distinguished name corresponding
to
   the target certificate, the acceptor needs to map the target name in
the
   SPKM request token.  I'm doing the following:

   a) A match occurs if the target name is the same as the subject name
or
      a DN entry for the subject alternate name in the target
certificate.

   b) A match occurs if the target name is just a common name and the
      common name matches the CN portion of the subject name or the CN
      portion of a DN entry for the subject alternate name in the target
      certificate.

   c) A match occurs if the target name is a service name
      ("CN=service/host") and the host matches the CN portion of the
      subject name or a DNS entry for the subject alternate name in the
      target certificate.

3) How does the initiator validate the target name?

   To avoid a man-in-the-middle attack, the initiator needs to validate
the
   fully-qualified target name.  So the initiator needs to perform the
same
   checking as described above to make sure the target name is
acceptable.

4) What character string should be returned by gss_display_name() for an
    anonymous name?

   GSS-API leaves this up to the security mechanism.  I'm returning the
   string "<anonymous>" although that is also a valid simple name.

5) How are certificates validated?

   I'm following the SSL model where the source provides its certificate
   and the certification chain up to the root certificate.  The target
then
   provides its certificate and the certification chain up to the root
   certificate.  Thus, the certification data consists of the forward
root
   certificate followed by any reverse certificates required to reach
   the user certificate.

   This requires each side to have a database of root certificates.
This
   database should already exist if SSL is being used.  Each side is
then
    responsible for validating the certificate supplied by the other
side.

6) How are the channel bindings encoded?

   RFC 2025 defines the channelId field as an octet string but doesn't
   indicate how the channel bindings specified by the application are
   converted to an octet string.  Since SPKM is attempting to follow
   Kerberos, I'm encoding the channel bindings in the same way as the
   Kerberos mechanism (MD5 digest of a flattened structure using
   little-endian length values).

7) How is the protocol version encoded?

   RFC 2025 doesn't specify whether the bits are numbered from
   left-to-right or from right-to-left.  Using the ASN.1 definition for
a
   bit string, bit 0 would be the most-significant bit, bit 1 would be
next,
   and so forth.  However, GSS-API numbers bits from right-to-left and
   thus bit 0 would be the least-significant bit.  I think the ASN.1
definition
   should be used (thus bit 0 would be x'80') but I've found an SPKM-1
   implementation from Systinet which does it the other way.

8) How are the context options encoded?

   Same problem as above.  Again, I think the ASN.1 definition should be
   used but the Systinet implementation encodes the options starting
   with the least-significant bit.  The Kerberos mechanism also encodes
the
   options starting with the least-significant bit (it actually encodes
them as
   a 4-byte integer in little-endian format).

9) How are integrity signatures encoded?

   PKCS #1 and RFC 2459 define the encodings for RSA and DSA
   signatures.  For RSA, the signature bit string is the encrypted
DigestInfo
   structure.  For DSA, the signature bit string is composed of two
   ASN.1-encoded integers.  However, this doesn't match the description
in
   RFC 2025.  I am using the PKCS #1/RFC 2459 encodings in my
   implementation.

10) How are the Diffie-Hellman parameters encoded?

   RFC 2025 uses the PKCS #3 OID instead of the RFC 2459 OID.  So I'm
   using the ASN.1-encoding defined in PKCS #3 instead of the
   ASN.1-encoding defined in RFC 2459.

11) How is the Diffie-Hellman public value encoded?

   RFC 2025 doesn't say whether it is the raw public value, the public
   value as an ASN.1-encoded integer, or an ASN.1-encoded sequence
   containing the public value as an ASN.1-encoded integer.  PKCS #3
   doesn't specify an encoding for the public value, so I am using the
raw
   public value as the value of the bit string.

Any thoughts on these choices or alternatives is welcome.  I've tried to
find a LIPKEY or SPKM-3 implementation to use for interopability
testing but have not been successful.

Ron Hoffman ([email-masked])

---

From: Mike Eisler <[email-masked]>
Date: Thu, 14 Mar 2002 09:43:14 -0800

> result, the code base differs significantly from the current MIT code.

Hello Ron,

I'm the author, but unfortunately, not an implementor. I'll
provide my two cents, and let the other known implementor,
Andy Adamson of UMICH/CITI, contradict me.

A lot of the issues you raised were brought up within the CAT
working group when the LIPKEY internet draft was going through
working group last call. I argued then that issues of
underspecification would be resolved when LIPKEY and
NFSv4 were implemented. So it looks like that time has
arrived. Excellent.

>    initiator does not have access to the target certificate?

What name type are you passing in? NFSv4 cares only
about GSS_C_NT_HOSTBASED_SERVICE when using SPKM-3.

Also you mentioned that you are done with _init_sec_context
and moving on to _accept_sec_context. However,
wouldn't the client side (initiator) need to do an
_import_name() before _init_sec_context?

>    single RDN sequence.  For example, "John Doe" is encoded as

What name type does your code use for this case?

>    For example, "[email-masked]" is encoded as

Presumably your code uses a  GSS_C_NT_HOSTBASED_SERVICE
name type for this case.

I'm not sure it makes sense to convert [email-masked] to
CN=nfs/server.sun.com.
RFC 3010 suggest the uses of nfs/hostname for Kerberos V5 and LIPKEY
service
names (and then goes on to suggests that LIPKEY not be used when
ever the NFS server is identfying itself to the client during a
callback.
Instead, it suggests to uses SPKM-3. The model I had in mind for
LIPKEY/SPKM-3 was that it would work in much the same way that
SSL is deployed today, and would try to leverage as
much of the existing SSL infrastructure as possible. As far as I can
tell, SSL
server certificates use a CN="server.sun.com". So,
the simplest would be to assume the use of the SSL-style
certificate ... I don't know if Verisign, Thawte, et. al.
will sell server certificates with arbitrary CN= values.

There may be implementation/deployment situations where one
may not be able to use the SSL certificate for NFS. E.g.
there might be both SSL and NFSv4 services running on the
same host, and for rationale security purposes, the
private key is not shared between the two.

So I suggest that NFSv4 follow this convention (and
the follow on to RFC 3010 be suitably revised)

	- try host@server first. A service name of
		"host" has a special meaning in GSS-API
		(see section 4.1 of RFC 2743 - GSS-API)
		For SPKM-3, that will always mean
		CN=server
	- if that fails, then fall back to nfs@server.	
		For SPKM-3, that will mean CN=nfs/server.

The notion of trying host@server, and then nfs@server
is one that RFC 2743 (againt in section 4.1) suggests is reasonable.

>    A distinguished name is used as-is.

What name type does your code use here?

>       portion of a DN entry for the subject alternate name in the target

This case doesn't seem to apply to NFSv4, since targets are
the service@server form.

>       subject name or a DNS entry for the subject alternate name in the

Right, but I suggest modifying to have allow target names
of "CN=server" per my answer to your first question.

>    checking as described above to make sure the target name is

Right. For NFSv4's use case, "CN=server" is simplest.

>    string "<anonymous>" although that is also a valid simple name.

I think that's fine, but I'll let you and Andy reach an agreement. :-)
In practice, I don't think it impacts interoperability if two different
implementations use different strings, but I could be wrong.

>     responsible for validating the certificate supplied by the other

Right. That was precisely my intent. ~user/.netscape/cert7.db
would be one useful source of root certificates.

>    little-endian length values).

Seems reasonable. I admit to never understanding the channel bindings
stuff.
This 
>    and so forth.  However, GSS-API numbers bits from right-to-left and

What are you referring to when you says that "GSS-API numbers bits ..."

>    implementation from Systinet which does it the other way.

It seems to me the ASN.1 definition ought to be used.

>    a 4-byte integer in little-endian format).

ditto.

>    RFC 2025.  I am using the PKCS #1/RFC 2459 encodings in my

Could you elaborate by pointing the respective sections in
RFC 2025 and RFC 2459 that disagree?

>    ASN.1-encoding defined in RFC 2459.

It seems to me theDH  parameters RFC 2459 specifies are far
DH certificates, whereas the purpose RFC 2025 has in mind is
for secure key exchange ... the target could be using an RSA-based
certificate.  So I think your choice is correct.

>    public value as the value of the bit string.

I think this relates to question Andy raised with me at Connectathon.
RFC 2025 discusses this field in the Req-contents token.

	key-estb-req      BIT STRING OPTIONAL,
              -- key estb. parameter corresponding to first K-ALG in set
              -- (not used if initiator is unable or unwilling to
              -- generate and securely transmit key material to target).
              -- Established key must satisfy the key length constraints
              -- specified in Section 2.4.

Andy pointed out that RFC 2025 and RFC 2847 are unclear
about what to use for key-estb-req and key-estb-rep
when using the dhKeyAgreement key K-ALG. The comment
about "unable or unwilling to generate and *securely*"
concerned him. My reading of the PKCS-3 standard
is that the public value (PV) doesn't have to be encrypted,
and moreover, the whole point of dhKeyAgreement is
boot strap the problem of generating a common
symmetric key. Furthere, the only
possible interpretation I can make from this text in RFC 2025,

        dhKeyAgreement OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
           pkcs-3(3) 1
        }

            In this algorithm, the context key is generated jointly by
            the initiator and the target using the Diffie-Hellman key
            establishment algorithm.  The target must therefore respond
            to the initiator for the key to be established (so this
            K-ALG cannot be used with unilateral authentication in
            SPKM-2 (see Section 3.1)).

is that initiator sends its PV in the key-est-req, and
the target responds with its own PV in the key-est-str,
each in the clear.

As to how the PVs are encoded, RFC 2025 specifies:

	key-estb-req      BIT STRING OPTIONAL
	...
	key-estb-str      BIT STRING OPTIONAL

So, my interpretation is an ASN BIT STRING.

> testing but have not been successful.

I suspect Andy might be willing to help there. :-)

---

From: "Ron Hoffman" <[email-masked]>
Date: Thu, 14 Mar 2002 16:55:48 -0500

Hi Mike,

The following functions are handled entirely in the
GSS-API router layer and have already been implemented.
I just needed to update them to understand the SPKM name
formats and to call mechanism-layer functions as needed (for
example, gss_add_cred calls the mechanism-layer
spkm_acquire_cred)

  - gss_add_cred
  - gss_add_oid_set_member
  - gss_canonicalize_name
  - gss_compare_name
  - gss_create_empty_oid_set
  - gss_display_name
  - gss_display_status
  - gss_duplicate_name
  - gss_export_name
  - gss_import_name
  - gss_indicate_mechs
  - gss_inquire_cred_by_mech
  - gss_inquire_mechs_for_name
  - gss_inquire_names_for_mech
  - gss_oid_to_str
  - gss_release_buffer
  - gss_release_name
  - gss_release_oid
  - gss_release_oid_set
  - gss_str_to_oid
  - gss_test_oid_set_member

The following functions are handled in the SPKM mechanism layer
and are invoked by the GSS-API router layer.  The router layer
already handles multiple mechanisms and just needed to have
the SPKM and LIPKEY layers defined as additional mechanisms.

  - gss_acquire_cred (done)
  - gss_context_time
  - gss_delete_sec_context
  - gss_export_cred
  - gss_export_sec_context
  - gss_get_mic
  - gss_import_cred
  - gss_import_sec_context
  - gss_init_sec_context
  - gss_inquire_context
  - gss_inquire_cred (done)
  - gss_process_context_token
  - gss_release_cred (done)
  - gss_unwrap
  - gss_verify_mic
  - gss_wrap
  - gss_wrap_size_limit

While NFS may not need some of these capabilities, my code is not
part of our NFS product but is part of our GSS-API product.  So I need
to provide the full support as defined by RFC 2743 and RFC 2744 (which
we already do for the two Kerberos mechanisms)

The X.509 certificate services are supplied by the PKI
support in our SSL product (which I also wrote, so it makes it
easier for me to understand some of the details).  The PKI support
is packaged as a separate load library which can be used
independent of the SSL layer.

So, to answer your first question, the initiator acquired an initiate
credential, imported the target name, and then called
gss_init_sec_context.  I dumped the output token and have an
annotated listing if you or Andy want to see what was generated.  I'm
now
working on the gss_accept_sec_context() code which processes
the request token and generates the reply-ti token.  I'll then need
to write the second half of gss_init_sec_context() which processes
the reply-ti token and generates the reply-it token.  Finally, I'll
need to write the second half of gss_accept_sec_context()
which processes the reply-it token and completes the context
establishment.

I'm supporting GSS_C_NT_HOSTBASED_SERVICE and
GSS_C_NT_USER_NAME for SPKM and LIPKEY (the other
name types will generate just Kerberos principals and not
SPKM or LIPKEY names).  I need to make an accomodation for
Kerberos here since GSS_C_NT_USER_NAME is valid for the
Kerberos mechanism and gss_import_name() doesn't have a
parameter indicating the target mechanism.  So, for a simple name
such as 'john-doe@kerberos-realm', I will drop the Kerberos realm
when forming the SPKM and LIPKEY names.  This implies
that '@' cannot be used as part of an SPKM or LIPKEY name.
In addition, a service name such as 'service@host' becomes
'service/host', which implies that '/' should not be used as part
of an SPKM or LIPKEY name unless the name should be treated
as a service name (this is also a problem with Kerberos since
the lower layers of the Kerberos mechanism look for a multi-part
principal name when extracting the host name).

I would have preferred to not allow the Kerberos realm for
GSS_C_NT_USER_NAME but that code is already out in the
field (and has been for years).  I think a fully-qualified Kerberos name
should use gss_nt_krb5_name while an unqualified Kerberos
name should use GSS_C_NT_USER_NAME.  That way, the name
format is unambiguously specified by the OID (which is the intent).

I also want to handle a distinguished name for GSS_C_NT_USER_NAME.
So, if a name contains an '=' character, I'm assuming it is a
distinguished
name.  A better solution would be a different name type OID for a
distinguished name (with gss_display_name() returning the appropriate
OID based upon the name format).  I need to handle distinguished names
since that will be the name type returned for an SPKM mechanism name.
It can also be used in the general case to fully specify the target name
when initiating a new context.

There is also a problem with gss_display_name() since the application
doesn't get to select the display format.  For a name created using
gss_import_name(), the output from gss_display_name() is going to
be a Kerberos principal since that is the default mechanism.  For a
mechanism name, the output will be the name returned by the
mechanism (Kerberos, SPKM, or LIPKEY).  This might be a simple
name or a distinguished name depending upon what exchanges have
been performed (for example, the source name returned by
gss_accept_sec_context() will be either the subject name from
the source certificate or an anonymous name).  At least here you can
tell the difference since gss_display_name() will return
gss_nt_krb5_name
for a Kerberos principal (which is always fully-qualified).  The
distinction
between a user name and a service name is lost at this point since
everything is a principal.  I don't think I can change this without
breaking
existing applications.  Given this behavior, an SPKM or LIPKEY name
will return GSS_C_NT_USER_NAME in all cases (no distinction between
a user name and a service name).

On matching names, I will consider it a match if the target certificate
contains 'CN=hostname' and the target name supplied on
gss_init_sec_context()
is either 'CN=hostname' or 'CN=service/hostname'.  I will also consider
it a
match if the target certificate contains the subject alternate name
extension
and one of the DNS entries matches (this handles a host with multiple
DNS names
or a sysplex using load balancing to route requests to different hosts).

On using a canonical host name as mentioned in RFC 2743, that isn't a
good idea
if you use an unprotected mechanism to obtain the canonical name since
this is
open to man-in-the-middle attacks.  The recommended method is to use the
supplied host name without modification when performing the check (thus
the
use of the  DNS form of the subject alternate name in the certificate
for hosts
with multiple names - the subject alternate name can contain multiple
host names
while the subject name can contain a single host name).  Of course, this
assumes
the application specifies the complete host name since a DNS lookup
would be
required to resolve a partial host name anyways.

On bit numbering, RFC 2744 shows some layouts (for example, the major
status code) with bit 0 as the LSB and bit 31 as the MSB.  I agree that
we should
be using bit 0 as the MSB for ASN.1 bit strings since that make sense
and allows
the bit string to expand in the future.  I had written my code this way
and didn't even
give it a thought until I was looking at the output from the Systinet
SPKM demo.
So I figured I should ask just to make sure we all agree to use the
big-endian
notation when talking about bits in a bit string (by the way, this
reverses the actual
option definitions: for example GSS_C_DELEG_FLAG is defined as 1 and
would
be encoded as x'80' since it is bit 0 in the bit string).

On integrity signature, RFC 2025 says:

  Integrity ::= BIT STRING
        -- If corresponding algId specifies a signing algorithm,
        -- "Integrity" holds the result of applying the signing
procedure
        -- specified in algId to the BER-encoded octet string which
results
        -- from applying the hashing procedure (also specified in algId)
to
        -- the DER-encoded octets of "token".
        -- Alternatively, if corresponding algId specifies a MACing
        -- algorithm, "Integrity" holds the result of applying the
MACing
        -- procedure specified in algId to the DER-encoded octets of
        -- "token" (note that for MAC, algId must be one of the
integrity
        -- algorithms offered by the initiator with the appropriate
subkey
        -- derived from the context key (see Section 2.4) used as the
key
        -- input)

I took 'BER-encoded octet string' to mean the hash digest is represented
as
an ASN.1 octet string: first byte is x'04', next byte is the length (16
for MD5 or
20 for SHA-1), followed by the digest bytes.  Per PKCS #1, an RSA
signature
encrypts a DigestInfo structure consisting of the algorithm identifier
and the
digest bytes.  Per FIPS 186, a DSA signature uses the 20-byte SHA-1
digest
as input data and returns two 20-byte integers which are then encoded as
ASN.1
integers but not as an ASN.1 sequence (per RFC 2459).  So I just wanted
to
make sure that we were following these specifications and not using our
own
format (for example, SSL encrypts a 36-byte value consisting of the
concatenation
of the MD5 digest and the SHA-1 digest)

On DH public value, I agree that it doesn't need to be encrypted or
otherwise
protected.  My concern was just what is in the bit string itself.  I'm
using the
public value without any other encoding (that is, it is not an
ASN.1-encoded
integer) as the value of the ASN.1 BITSTRING field.  The source will
provide
its PV in the request token and the target will provide its PV in the
reply-ti
token.

Finally, the only key establishment algorithm is Diffie-Hellman since I
will
not have the target certificate.  The confidentiality algorithms will be
Cast5Cbc
and DesCbc.  The integrity algorithms will be HmacMd5,
Sha1WithRsaEncryption,
Md5WithRsaEncryption, DsaWithSha1, and DesMac.  The one-way-function
algorithms will be Sha1Digest and Md5Digest.

Thanks for your comments.

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Fri, 15 Mar 2002 13:13:34 -0500

Hi Ron

Have you seen the SPKM3 open source work that i've done? It's currently not 
available off our web site - i'll get an updated version asap. I would like to 
test against each other...

> about GSS_C_NT_HOSTBASED_SERVICE when using SPKM-3.

My SPKM-3 implementation requires the GSS_C_NT_HOSTBASED_SERVICE names.

> implementations use different strings, but I could be wrong.

At the University of Michigan, we hand out x509 certificate names in the 
following form:

a preamble,

 { "countryName",    "US" } ,
  { "stateOrProvinceName",  "Michigan" } ,
  { "localityName",   "Ann Arbor" } ,
  { "organizationName",   "University of Michigan" } ,
  { "organizationalUnitName", "TEST -- CITI Client CA v1"}

with a common name appended

 CN=nfs/hostname.  

These certificate names are used in our SSL communications - between browsers 
and web servers as well as for globus grid communicaitons.

i currently match all portions of the name. i feel the preamble is important 
in that it provides futher identity of the target.

> would be one useful source of root certificates.

if the client has a certificate, then the source name is known, not anonymous. 
What key exchange algorithm do you use?
i've implemented SPKM3 using diffie-hellman key exchange where the source has 
no certificate, and the target certificate is passed back to the source who 
verifies it via it's data base of root certificates.

> So, my interpretation is an ASN BIT STRING.

Yep. BIT_STRING is what I use.

> I suspect Andy might be willing to help there. :-)

yes!  i've been talking to myself far too long....

-->Andy

---

From: "Ron Hoffman" <[email-masked]>
Date: Fri, 15 Mar 2002 15:09:48 -0500

Hi Andy,

I have your SPKM3 source code from last July and would be interested in
your current source code.  I'm afraid there won't be much in common
since my code has diverged significantly since the first MIT Kerberos V5
release in 1997.  I've also rewritten a lot of the original MIT code for
performance, reliability, and serviceability improvements (my code is
part of z/OS which is one of the IBM mainframe operating systems).  In
addition, I'm using my own X.509 certificate and crypto routines instead
of the OpenSSL code (large portions of my crypto and math routines are
written in S/390 assembler for performance reasons).

I would be interested in getting the binary tokens generated by calls to
the various GSS-API routines.  I could then break them down to see if
your encodings match my own (I've gotten pretty good at ASN.1 over the
past couple years after writing ASN.1 encoders/decoders without using an
ASN.1 compiler).  I also have an AIX (Unix) system running MIT Kerberos
and OpenSSL which I use for interoperability testing.  I could apply
your updates to MIT Kerberos and do some interoperability testing that
way.

I expect NFS to use GSS_C_NT_HOSTBASED_SERVICE.  However, the RFC
specifies both GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE.  Since
our GSS-API support is separate from the NFS support, I'm going to try
to provide a full implementation of RFC 2743 and 2744.  It would be nice
if we had a third name type for an X.509 distinguished name.  That way,
I wouldn't need the kludge of checking for an '=' in the name to decide
if it was a simple name or a distinguished name when GSS_C_NT_USER_NAME
is specified.  gss_display_name() could then return this new name type
for an SPKM mechanism name (since those names will be obtained from
X.509 certificates and will be distinguished name).

In your code from last July, you are hard-coding the suffix for the
target name.  I ended up sending the target name as just
'CN=service-name/host-name' in the SPKM request token.  No suffix is
added at this point.  The target then checks the name against its X.509
certificate (following the rules I described in my previous post).  If
the name is acceptable, context establishment proceeds.  On the second
call to gss_init_sec_context(), the target name is updated in the
context using the subject name from the supplied certificate (I always
request the target certificate).  The application can obtain this name
if desired by calling gss_inquire_context().

If a distinguished name is provided for the target name, then it must
match either the subject name or one of the subject alternate names in
the target certificate.  So applications that want an exact match on the
target name can be accomodated as well as applications that just want a
match on the host name.  I could also provide an environment variable
for specifying the name suffix (I already have environment variables for
specifying the key database and the default certificate).  This suffix
would be added to any simple name.  The trouble is making it flexible
enough to handle the case where you are accessing servers in different
enterprises.  If we assume the certification authorities will be strict
about the assignment of host names in certificates, we probably don't
need a suffix on the target name.

I always use Diffie-Hellman key exchange since I don't have the target
certificate when generating the request token.  The source certificate
and certification chain are included in the request token unless the
GSS_C_ANON_FLAG is specified.

I agree that the DH public value is encoded as a BIT STRING in the
request and reply tokens.  My question relates to how the bit string is
constructed.  Say you have a 128-byte public value (Y) as output from
the DH key agreement algorithm.  Does the bit string consist of just
this 128-byte value?  Or is the public value encoded somehow and the
encoded result becomes the bit string value?

If the BIT STRING consists of just the 128-byte Y, then the encoded
result would be: x'03818100yyyyyyyy.....yyyy'

However, in your July code, it looks like you take Y and encode it as an
ASN.1 INTEGER and then wrap that in an ASN.1 SEQUENCE.  The encoded
result is then: x'03818700308183028180yyyy......yyyyy'.

A similar question relates to other bit strings.  For example, if I
generate an 8-byte random number R, I'm assuming the encoded result
would be: x'030900rrrrrrrrrrrrrrrr'.  That is, the random number is not
first encoded as an ASN.1 INTEGER and the encoded result then used as
the bit string value.

Ron

----- Original Message -----
From: "William A.(Andy) Adamson" <[email-masked]>
To: <[email-masked]>
Cc: "Ron Hoffman" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, March 15, 2002 1:13 PM
Subject: Re: LIPKEY and SPKM-3 support