Subject: R: R: R: Digital Signature Implementation Interoperability

From: "Santoni Adriano" <[email-masked]>
Date: Tue, 2 Nov 2004 09:32:46 +0100

I do not know which italian Certification Authority is using your crypto toolkit, to date.  In any case, I can very confidently deny that the italian interoperability rules mandates such weird things as you describe below.  

In particular:
- there is definitely no "requirement to use Unicode (BMPString) for an attribute "; it is permitted to do so in the description RDN; and description has a DirectoryString syntax (from x.520), so it can take on a BMPString if needed; of course this proviso is now obsolete; in the next future we will use UTF8String....
- there is no proviso for "funny custom handling of basicConstraints";
- there is no proviso for "an altName consisting of a multi-line LDAP URL that points back ..."; it may have been someone's broken implementation;
- "multiple SignerInfos per SignedData " is a perfectly standard and useful PKCS#7 feature; only toy applications "will only display the first one".

Adriano

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

"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.

*******************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: Tue, 02 Nov 2004 22:23:54 +1300

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

>I do not know which italian Certification Authority is using your crypto
>toolkit, to date.

It's not one, it's (based on different email addresses that I've had requests
from) between half a dozen and a dozen organisations (since it's OSS and this
was over a period of years it's not really possible to accurately track all
this, and in particular recent versions have been modified to handle various
peculiarities so I'd be getting less mail about them).

>- there is definitely no "requirement to use Unicode (BMPString) for an
>attribute ";

All I can do is respond/react to requests as I get them.  To use this
particular one as an example:

  I have implemented all properties for testing Cryptlib and only one of this
  I could not have set easily, the <Description> property (2.5.4.13)
  [...]
  The property must be set with BMPString type...

(The problem here was that cryptlib used PrintableString since BMPString was
 unnecessary, so they had to change it to force use of a BMPString).

All I can report (for this and all the other stuff) is what users come to me
to ask for, and that's a long list of some variation of "Italian
regulations/guidelines require that we do X", where X is usually something
really strange.  Maybe it's just that all of them are doing strange things
that they've created themselves rather than being required to by any
specification, or are having to accomodate buggy software, but it does seem a
bit unusual that there's so much of that then concentrated in Italy, since
you'd expect to see it evenly distributed over all countries.  I'm not able to
speculate on the cause of this phenomenon, but something is *really* promoting
OSS crypto use there :-).

Peter.