Subject: Generating Key Pair

From: "chandrasekaran natarajan" <[email-masked]>
Date: Fri, 05 May 2000 06:19:01 -0700

hello,

How do CA's request the browser to generate the keypair.

with thanks,
chandar

Get your FREE Email at http://mailcity.lycos.com
Get your PERSONALIZED START PAGE at http://my.lycos.com

---

From: Michael Sierchio <[email-masked]>
Date: Fri, 05 May 2000 08:10:21 -0700

> How do CA's request the browser to generate the keypair.

Netscape has built-in support for generating a keypair, and the
ubiquitous 'xenroll.cab' and some supporting VBScript (ack!)
enable IE to do the same.  In the case of Netscape, an HTML
form which includes a <KEYGEN ...> tag will cause the browser
to display a pull-down box to choose RSA modulus length.

In both cases, you'll need to bake the Certificate Request
from the form elements.  IE will post what looks like a PKCS#10
cert req, but is somewhat degenerate, and Netscape will post
a SPKAC (signed public key and challenge) as the keygen value.

This has nothing to do with the CA, really -- it's all web
stuff up to the point where a cert req is presented to a CA.

The web-based enrollment could be a function of a local RA...

====================Netscape Version==========================

<FORM METHOD=POST ACTION="/enroll2">
<hr><em><b>Please enter the following data to get your personal
certificate:</b></em>
<TABLE>

<TR>
<TD> Your name </TD>
<TD><INPUT TYPE=text SIZE=40 NAME="name" VALUE="Joan Q. Public"></TD>
</TR>

<INPUT TYPE=hidden SIZE=30 NAME="unit" VALUE="JWS">
<INPUT TYPE=hidden SIZE=30 NAME="org" VALUE="Java Land">
<INPUT TYPE=hidden SIZE=30 NAME="unit" VALUE="BOZO">

<TR>
<TD> City or Locality name </TD>
<TD><INPUT TYPE=text SIZE=30 NAME="locality" VALUE="San Mateo"></TD>
</TR>

<TR>
<TD> State or Province name </TD>
<TD><INPUT TYPE=text SIZE=30 NAME="state" VALUE="California"></TD>
</TR>

<TR>
<TD> Two-letter country code (e.g. <em>US</em>).</TD>
<TD><INPUT TYPE=text SIZE=2 NAME="country" VALUE="US"></TD>
</TR>

<TR>
<TD> Your preferred key size </TD>
<TD><KEYGEN name="keygen" challenge=fixed-for-now></TD>
</TR>

</TABLE>

<INPUT TYPE="hidden" NAME="opname" VALUE="genCert">

<P>
<CENTER>
<INPUT TYPE="submit" VALUE="Request Certificate">
<INPUT TYPE="reset" VALUE="Clear Form">
</CENTER>

</FORM>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 05 May 2000 16:00:23 -0400

I have just completed a 3 day CMP2000 interop workshop (email me if you 
wish to participate in the next one 1st week in June).

In the days preceeding and during we yet again had vendors experiencing 
ASN.1 coding problems with Name.

I have had threads as follows:

=============================================================

now I have examined the problem [with your ir] in more detail: Our Code
has problems with the field 'subject' [5] in the CertTemplate: The subject
is a NAME and the default for tagging in the CertTemplate SEQUENCE
is IMPLICIT.

Now the problem is, that the NAME  is a CHOICE and for a CHOICE
it is not allowed to use IMPLICIT tagging (see the ASN.1 specification).
So, in the case of  NAME one has to use an EXPLICIT tagging.

=============================================================

Then I get others like:

=============================================================

my interpretation of the PKIHeader->sender/recipient field was
as follows:

both sender and recipient are defined to be of type GeneralName...

      PKIHeader ::= SEQUENCE {
          pvno                INTEGER     { ietf-version2 (1) },
          sender              GeneralName,
          -- identifies the sender
          recipient           GeneralName,
          -- identifies the intended recipient
          messageTime     [0] GeneralizedTime         OPTIONAL,
          <snip>

which is defined in the IMPORTS as:  FROM PKIX1Implicit88

which is defined in RFC-2459 as:

GeneralName ::= CHOICE {
      otherName                       [0]     AnotherName,
      rfc822Name                      [1]     IA5String,
      dNSName                         [2]     IA5String,
      x400Address                     [3]     ORAddress,
      directoryName                   [4]     Name,
      ediPartyName                    [5]     EDIPartyName,
      uniformResourceIdentifier       [6]     IA5String,
      iPAddress                       [7]     OCTET STRING,
      registeredID                    [8]     OBJECT IDENTIFIER }

therefore it should be tagged as IMPLICIT
and, it can be any number of underlying structures.

so, a Name, although a SEQUENCE by definition, would be implicitly tagged
as [4] { SET{}  SET{} ... }, not SEQUENCE { SET{}  SET{} ... }

otherwise, the underlying name type would not be so easily determined.

=============================================================

As you might imagine, it is challenging to work on CMP interoperablity when 
there are questions about 2459 conformance.

Not everyone will be (or want to be) ASN.1 war heros.

What can we do with 2459bis to stop the flow of coding errors????

Do we need an informational RFC giving ASN.1 coding rules so that people do 
not have to get the X. whatever???

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]