Subject: R: R: Digital Signature Implementation Interoperability

From: "Santoni Adriano" <[email-masked]>
Date: Fri, 29 Oct 2004 10:45:26 +0200

> there are quite a number of extremely... unusual things in there that are used nowhere else on earth.  So this isn't really a valid sample

I am not aware of any particular complication. Would you please describe the most unusual things that you had to comply with?

The only "unusual thing" that I am aware of, regarding italian interoperability rules, is that we currently use commonName's containing unusual stuff formatted in an unusual way. But that is not against any standard.

Adriano

-----Messaggio originale-----
Da: pgut001 [mailto:[email-masked]] 
Inviato: venerdì 29 ottobre 2004 9.53
A: [email-masked]; [email-masked]
Cc: [email-masked]
Oggetto: Re: R: Digital Signature Implementation Interoperability

"Santoni Adriano" <[email-masked]> writes:

>Among the several CSP's accredited in Italy (by www.cnipa.gov.it) under 
>our national legislation on digital signatures and associated 
>regulations, there is close to 100% interoperability as far as PKCS#7 
>signatures (RFC 2315) and associated qualified certificates are 
>concerned.

As the provider of a security toolkit that has to comply with the Italian requirements, I should add that the it's a helluva lot of work to get that interoperability.  It's caused me more problems than any other signature law/requirements because there are quite a number of extremely... unusual things in there that are used nowhere else on earth.  So this isn't really a valid sample, it's like the joke about portability where someone claims that their code is portable because it runs on every VAX 11/750 running 4.3BSD Tahoe that they've tried it on.

Peter.

*******************Internet Email Confidentiality Footer*******************

Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati.
Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. 
ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. 
ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 30 Oct 2004 01:38:10 +1300

"Santoni Adriano" <[email-masked]> writes:

>I am not aware of any particular complication. Would you please describe the
>most unusual things that you had to comply with?

Oh dear, where should I even start?  This is just off the top of my head, but
the list includes wierd custom attributes in DNs, some funny custom handling
of basicConstraints (can't remember the exact details, but Italian users
required a code patch to alter the behaviour from the standard one), a
requirement to use Unicode (BMPString) for an attribute that, for some
unfathomable reason, everyone else claims is an IA5String (that's the one
where I joked that the people who created the requirement owned Microsoft
stock, because seeing that string type would at the time crash Netscape
browsers), an altName consisting of a multi-line LDAP URL that points back to
the certificate that contains the altName (God knows what the semantics for
being able to "process" that extension would be, I guess you'd be required to
go into an endless loop), use of message formats that are *only* valid
according to the somewhat more lax terminology in PKCS #7 but invalid under
CMS, use of multiple SignerInfos per SignedData (many apps will only display
the first one), really weird stuff involving timestamps that I've stopped
trying to figure out (I've had to resort to "You've got the source code, feel
free to implement what you need" because it just isn't worth the effort of
accomodating a one-off special-case like this), and then about two or three
times as many more strange bits and pieces that I'd have to go back through
mail archives to dig up (every now and then I'll get some piece of mail that
starts with "The Italian digital signature requirements require..." and my
reaction will be "Oh no, what's it going to be this time?").  Now having said
that I have to say that I *love* the Italian requirements, as the author of an
open-source toolkit, I get to play in a market that no standard commercial
toolkit (or at least none that hasn't had extensive customisation) can touch
:-).

(I'm not just being facetious about this, I've heard this from a number of
 users, they have to go with an OSS toolkit whose behaviour they can modify
 themselves because no unmodified off-the-shelf one will work.  So in a way
 this is strongly promoting OSS, although it probably wasn't intended that
 way).

>The only "unusual thing" that I am aware of, regarding italian
>interoperability rules, is that we currently use commonName's containing
>unusual stuff formatted in an unusual way. But that is not against any
>standard.

Nor is putting an MPEG of a cat in the DN, but it hardly promotes
interoperability, which is what you were talking about in your original
message.

Peter.