Subject: IESG discuss item on CGA: RSA key encoding details, random number generator, key lifetime

From: Pekka Nikander <[email-masked]>
Date: Fri, 12 Mar 2004 10:40:43 +0200

Folks,

As I wrote before, we have one discuss item from the
IESG on the CGA draft.  The purpose of this message is
to start discussion on this, in order to reach WG
consensus on the required changes as soon as possible,
preferably before the end of this month.

Russ Housley writes:
>   The first paragraph of section 3 says:
>   >
>   >  ... For SEND, the public
>   > key SHOULD be an RSA encryption key with the object identifier
>   > rsaEncryption (i.e., "1.2.840.113549.1.1.1") and the subject public
>   > key field SHOULD be formatted as an ASN.1 data structure of the 
> type
>   > RSAEncryptionKey defined in [PKCS.1.2002]. ...
>   >
>   PKCS #1 v2.1 (14 June 2002) does not specify a type of 
> RSAEncryptionKey.
>   I suspect that a type of RSAPublicKey is intended.  This type and
>   the associated object identifier can be found in RFC 3279 (as well as
>   in PKCS #1 v2.1).  The community will be able to easily locate RFC 
> 3279.
>   Please refer to section 2.3.1 of RFC 3279.

I see the reference to RFC3279 as a detail and I see no problem
in fixing this.

>   Further, the use of SHOULD bothers me.  The use of RSA can be 
> SHOULD, but
>   the format of fields when RSA is selected ought to be a MUST.  I 
> suggest:
>
>     SEND SHOULD use an RSA public/private key pair.  When RSA
>     is used, the algorithm identifier must be rsaEncryption, which
>     is 1.2.840.113549.1.1.1, and the RSA public key MUST be formatted
>     using RSAPublicKey type as specified in section 2.3.1 of RFC 3279.

To me this looks fine.  It leaves it open what format to use if RSA
is not used, which sounds fine to me.  At the same time, it is very
specific of the format for RSA keys, which also seems fine to me.

>   In the 1st full paragraph on page 9, Section 4 says:
>   >
>   > ... The quality of the random number generator does not affect the
>   > strength of the binding between the address and the public key. ...
>   >
>   This kind of statement will encourage implementors to use a constant,
>   which is a problem.  A SHA-1 hash of the time of day would be okay.

Apparently we need some new wording here.  Tuomas, could you please
suggest some wording?

>   Section 7.3 ought to reference RFC 1750.

1750 is "Randomness Recommendations for Security". This seems to be a
clear case.  It looks like that the best place for the reference
is after the first paragraph in 7.3.

>   The security considerations ought to say something about the lifetime
>   of the public/private key pair.  The one brief statement in section 
> 7.3
>   is not sufficient for an implementor to know how often the key pair
>   needs to be changed.

This seems to require some more consideration, as there may be
conflicting goals.  Some nodes prefer stable addresses.  Some
nodes prefer relative anonymity.

But we seem to require some new text.  Tuomas, can you suggest
a wording?

--Pekka

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.