Re: SV: new profile submitted

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

I absolutely and vociferously agree with Nada.

Changing the size of the key ID this late in the game is ABSOLUTELY 
UNACCEPTABLE for anything less than an end-of-the-world kind of problem.

As part of the effort to ramp up for the release of Novell's NetWare 5.0 next month,
we are in the process of generating Foundation Key Sets containing 7 certificates 
each, with an initial run of over 200,000 Foundation Key Sets. Running flat out
on our Wang XTS B3 machine, it will take about a month to complete this
process. Since we sent out over 200,000 copies of the beta alone, I would 
expect that by the end of the year, there will probably be on the order of 
3.5 million certificates out there and presumably in use, with people starting to 
generate their own certificates using our CA product.

All of the keyIDs in those certificates use a 160 bit SHA-1 hash.

I can only imagine what will happen if this impacts Windows 98.
The IETF will suddenly have become irrelevant.

If this is last call, I will have to vote a strenuous NO unless this is changed.  
It's simply too late in the game.


Bob




Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman@novell.com

"Architects, like prophets and saints, are 
usually years ahead of their time. For this
reason they are often difficult to live with
at home, especially if they turn out to be 
right."


>>> Nada Kapidzic Cicovic <nada@cost.se> 06/24 4:08 AM >>>
I do not understand the point of changing the key id calculation algorithm
this late in pkix part 1 last call. 

Is the size of the resulting key id the only problem with the old algorithm
definition?

Is this size really an issue for S/MIME messages?

I would prefer changing the definition back to what it was, since we have
already released the software implementing it in the old way, and we are
probably not the only one.

Regards,

Nada


At 20:55 6/23/98 -0400, Russ Housley wrote:
>The PKIX Part 1 key identifier will be used in S/MIME to identify the
>per-recipient information necessary for a recipient to perform decryption.
>As stated in a previous message, collisions are not a problem here.
>However, this key identifier will not be used to identify a particular
>certificate used by an originator to sign a message content.  Collisions
>could cause significant confusion in this circumstance.
>
>Russ
>
>
>At 12:11 PM 6/23/98 -0700, Paul Hoffman / IMC wrote:
>>I think the question here is whether or not it is useful to have the same
>>key identifier for both PKIX part 1 and OCSP. If it is, then we need to
>>choose one that works for both. Ambarish says that 60 bits, with the
>>possibility of collision, is not strong enough for OCSP. If that's true, we
>>need to decide if the two key identifiers have to be the same, or whether
>>we can use a shorter one for PKIX part 1 and a longer one for OCSP.
>>
>>--Paul Hoffman, Director
>>--Internet Mail Consortium
>> 
>