ietf-smime
[Top] [All Lists]

RE: Recommendation on subject matching rules needed..

2003-03-11 08:02:04

[Also CC'd to S/MIME]

"Vainikainen Saku EINT" <Saku(_dot_)Vainikainen(_at_)elisa(_dot_)fi> writes:

It seems that all the software we have tested (eg. MSoft, Utimaco)

Everyone, not just those two.

OK - this is more or less what I assumed :( Do you know if there is any work
being done on this subject in terms of a recommendation
paper/draft/something?

See my previous message.  It's really an application/policy issue, I don't
know if there's much to say in standards except maybe to post a skull and
crossbones next to a description of the problem to let people know what
they're in for.

Our cards (=certs) are valid for three years. If the card has been in use for
2 years when we reissue it with recovered enc key, we need to reissue the enc
cert also - otherwise the recovered enc key cert could be usable only for one
year whereas the other certs would be usable for three years.

Why not just leave the decryption key as is and issue a new 3-year decryption
cert?  This in effect is what I do in my code (with the date-based transparent
rollover).

Also - if we pile up all the previous enc certs to the card along with the
new cert, we run out of card space as well as introduce new problems since
the apps usually don't iterate though all the certs and end up using the
first cert available.

Can you fit 4 keys?

(On a completely unrelated topic, are you sure the software you're using is
 able to make sense of the NR key there?  A lot of software is totally
 incapable of distinguishing between signature and NR keys, and just takes the
 first one that it finds with {signature,NR} enabled.  For that matter, I've
 found a number of card issuers in [looks at sender's country code], uhh,
 well, Scandinavia who set PKCS #11 key usage bits incorrectly on cards, so
 you get crypto keys marked as signing keys and vice versa, or all keys marked
 as crypto or signing keys, or other oddities, and no-one even notices that
 they're encrypting with the NR key.  The point is that if your software can't
 differentiate between signature and NR (or even all three key types), you
 could dump the NR key and add an extra encryption key instead).

Peter.