Subject: RE: QC Declaration

From: Stefan Santesson <[email-masked]>
Date: Sat, 15 Mar 2003 00:46:20 +0100

Sharon and all,

I've heard many answers but the questions that needs them has not yet ben 
formulated.

Lets get back to this issue and do that.

Facts:

1) Current definition of the qcStatements ext says that if the extension is 
critical then all statements are critical.

2) It is compliant with X.509 to state that if an extension is critical, it 
is OK to recognize at least 1 of the contained elements. It is however 
unlikely that this is a good solution for the qcStatements extension, due 
to legacy and the different nature of different statements.

3) If one would set this extension as critical, it is likely that many 
applications would reject the certificate. This could be true also over 
time in the future since many local statement could be defined that would 
not be supported by clients in general.

Questions:

a) Is there any case/context where fact 3 actually is not a problem, but 
rather a feature?

b) could any such context be clearly defined and included in RFC 3039bis or 
any local standard?

Answers:

Question a)
Yes there has been situations raised where fact 3 actually could be a feature.

Many has complained about the problem to isolate a particular certificate 
for use in only electronic signature applications where the content is 
clearly presented and accepted by the signer prior to signing. The key 
usage or extended key usage extensions are not ready to provide this 
functionality. At least not today.

So, given that we would have a certificate that we WANT applications in 
general to reject it. A certificate that we only want those applications 
that are trained and designed to accept it,  to actually accept it. Then 
this could in fact be a great feature.

It could be the mechanism that would force all low grade applications to 
reject its use, and thus increase its evidence value when it is used.

b) It is true that the case described in answer a) does not apply to all 
certificates. But given that there are cases where it is of great value to 
isolate certificates use to informed applications. Then it might as well be 
worth the effort to try to formulate one or some clear contexts where 
setting the extension critical ought to be mandatory OR at least recommended.

Opinions:

My opinion is that it is our responsibility to look seriously into this 
issue with open minds before we reach a definitive conclusion to answer b). 
Personally I do believe we have a chance to contribute in a good way to 
supporting good use and acceptance of electronic signatures and believe 
that such context could and should be formulated.

/Stefan

At 15:19 2003-03-12 -0500, Sharon Boeyen wrote:
>It would have been compliant IF the semantics of the extension stated 
>that. However, the semantics of the extension dictate the opposite where 
>ALL statements are critical.
>-----Original Message-----
>From: Stefan Santesson [mailto:[email-masked]]
>Sent: Tuesday, March 11, 2003 4:49 PM
>To: Sharon Boeyen; [email-masked]
>Subject: RE: QC Declaration
>
>Sharon,
>
>The first step for me is to get the mechanics right.
>
>Are you saying that it would have been compliant with X.509 to declare 
>that a critical QCStatement (disregarding the current declaration in RFC 
>3039) is valid if I can process at least one of the present statements 
>(similar to SubjectAltName).
>
>Not that I claim that it would be a good idea.
>
>/Stefan
>
>
>At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:
>>I don't want to get off on a non-relevant tangent regarding criticality, 
>>but think I do need to clarify a little bit on the subject Alt Name 
>>extension. If you check 8.3.2.3 (509) you'll find that the semantics of 
>>that extension are such that, if set to critical, "at least one of the 
>>name forms that is present shall be recognized and processed ...". So if, 
>>in your example, the ONLY name present in subjectAltName extension is the 
>>unknown otherName OID, then you are correct and the certificate shall be 
>>considered invalid. If however, that unknown otherName OID was present 
>>AND and rfc822Name was present - the RP might understand the rfc822Name 
>>and check it against the intended recipient of an encrypted email for 
>>example, and under those circumstances the certificate would be valid, 
>>even though the extension was critical and there was another nameform in 
>>there that was not understood.
>>
>>I suspect that its probably a bit too soon to profile the kind of 
>>contexts I think you're describing in 3039. I'd prefer to see a bit more 
>>practical use of QCs first so that we have a better handle on what 
>>constitutes a "context". For example, perhaps one context is with the 
>>ETSI qcstatement 1 plus a specific national qc statement and if both are 
>>present in a certificate that some 'authority' (I don't mean a CA here) 
>>deems that when that combination is present the extension shall be set to 
>>critical. I'm not necessarily opposing the idea, just a little 
>>uncomfortable with the proposed timing without significant real world 
>>deployment to guide us with to the appropriate 'contexts'.
>>
>>Cheers,
>>Sharon
>>-----Original Message-----
>>From: Stefan Santesson [mailto:[email-masked]]
>>Sent: Tuesday, March 11, 2003 4:06 PM
>>To: Sharon Boeyen; Sharon Boeyen; [email-masked]
>>Subject: RE: QC Declaration
>>
>>Sharon,
>>Thanks for the clarification.
>>"Elements of the syntax" really clarifies things.
>>So it is OK to accept an certificate with a critical policy extension 
>>containing an policy OID that I don't recognize, because it doesn't 
>>define any further syntax of the extension.
>>The same goes with Extended key usage OIDs.
>>However. It would not be OK with a critical subjectAltName containing an 
>>unknown other name OID, since this OID would define further syntax.
>>By the same reason I would need to understand all present QCStatements 
>>OIDs, because they do the same (define further syntax).
>>Let me clarify that I never proposed that the QCStatement must be 
>>critical in all certificates.
>>I'm just recognizing that it might be a valuable practice within certain 
>>contexts and the fact that some implementers actually ask for it.
>>The question is whether any of those contexts can be identified within 
>>RFC 3039, or if they are better placed in local sub-profiles (Such as 
>>ETSI TS 101862), or if they don't exist in a way that can be standardized 
>>in a meaningful way.
>>
>>/Stefan
>>
>>At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:
>>>Hi Stefan,
>>>
>>>Remember first that RFC 3280 is a "profile" of X.509 and it does not 
>>>replace the requirements of 509, but rather profiles them to a subset.
>>>
>>>X.509 in clause 7 allows unknown elements in non-critical extensions 
>>>only to be ignored. However, that is more with respect to the elements 
>>>in the syntax
>>>itself (for example in the IDP extension no RP is allowed to ignore the 
>>>"onlySomeReasons" element if it is present in the extension because the 
>>>extension
>>>can only be critical. The behaviour of RPs will differ however depending 
>>>on their specific capability with respect to that element (some will use 
>>>the CRL for
>>>the specified reasons and others will seek a different CRL that covers 
>>>all reasons), however, no RP is permitted to simply ignore the flag. 
>>>Note also that in that
>>>same clause, for extensions that can be marked critical or non-critical, 
>>>a system that understands the extension is required to process it 
>>>regardless of the
>>>value of the criticality flag. It is ONLY systems that do not understand 
>>>an extension that can ignore it completely if it is marked non-critical.
>>>
>>>For the QC Statements extension, RFC 3039 says "This extension may be 
>>>critical or non-critical.  If the extension is critical, this means that 
>>>all statements
>>>included in the extension are regarded as critical. "
>>>
>>>Because of the semantics defined for the extension in RFC 3039, marking 
>>>it critical would result in the problems I raised.
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[email-masked]]
>>>Sent: Tuesday, March 11, 2003 11:23 AM
>>>To: Sharon Boeyen; [email-masked]
>>>Subject: RE: QC Declaration
>>>
>>>Hi Sharon,
>>>My interpretation of criticality does not really match yours.
>>>The only guidance on the meaning of criticality in RFC 3280 (section 
>>>4.2) that I can find is:
>>>
>>>
>>>
>>>
>>>   "A certificate using system MUST reject the
>>>
>>>
>>>certificate
>>>
>>>
>>>
>>>if it encounters a critical extension it does not recognize"
>>>
>>>My interpretation is that it is OK to accept a certificate if you 
>>>recognize the extension as such. You don't need to understand ALL 
>>>information that the extension contains.
>>>It seam vital to agree on this issue before we can make any conclusion 
>>>on QCStatament criticality.
>>>/Stefan
>>>At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
>>>>Hi Stefan,
>>>>While I believe that in the longer term certificate policies will be the
>>>>optimum
>>>>way to convey the necessary information, I acknowledge that QC 
>>>>Statements is
>>>>the
>>>>more popular scheme at present. Therefore I wouldn't have any problem 
>>>>should
>>>>this
>>>>extension be mandated in RFC 3039.
>>>>However, forcing its criticality is going too far I believe. There is an
>>>>important
>>>>difference between critical and non-critical extensions that we need to 
>>>>keep
>>>>in
>>>>mind from the relying party's perspective. If there is a non-critical
>>>>extension that
>>>>the RP understands, but that extension includes some elements that it does
>>>>not, then
>>>>the RP is free to process the parts it does understand and ignore 
>>>>others. If
>>>>an extension
>>>>is critical however, the RP is required to understand ALL elements within
>>>>the extension.
>>>>Where I think this can become a problem is the content of the QC 
>>>>Statements
>>>>extension. Note
>>>>that RFC 3039 and the ETSI profile define DIFFERENT statements for 
>>>>inclusion
>>>>in the extension.
>>>>Also additional profiles may add their own local statements and even
>>>>narrower statements can
>>>>get added in specific deployment environments. While the cert issuer may
>>>>want to include many
>>>>of these statements to enable the cert to be used in various environments,
>>>>the RP should only
>>>>be required to understand and process the statements that are 
>>>>appropriate to
>>>>its own
>>>>operating environment as dictated by its local security policy (which 
>>>>could
>>>>be different than
>>>>that under which the CA operated). Therefore I think requiring it to be
>>>>critical is risky.
>>>>Also requiring that it always be critical would have interop/backward
>>>>compatibility issues.
>>>>Cheers,
>>>>Sharon
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Stefan Santesson [mailto:[email-masked]]
>>>>Sent: Tuesday, March 11, 2003 8:27 AM
>>>>To: [email-masked]
>>>>Subject: QC Declaration
>>>>
>>>>The EU directive introduced a requirement on each CA, issuing QC 
>>>>(Qualified
>>>>Certificates), to clearly indicate in these certificate that they are
>>>>issued as QC.
>>>>ETSI implemented RFC 3039 in relation to the European electronic signature
>>>>directive through their Technical Standard (TS 101862)
>>>>TS 101862 specified 2 alternative ways to declare a certificate as QC.
>>>>1) By inclusion of a QCStatements extension
>>>>2) By including a certificate policy identifying this property
>>>>Even though solution number 1) is far easier to handle by applications,
>>>>since they don't need to recognize specific QC Policies, ETSI didn't make
>>>>solution 1) mandatory or even consider making it critical, due to lack of
>>>>confidence that clients would widely deploy this solution. ETSI needed to
>>>>define a solution that could work even if no one choose to implement the
>>>>new extensions provided by RFC 3039.
>>>>However, It is not feasible to keep clients updated over time with
>>>>different QC policies and even those policies that are regarded
>>>>standardized may be updated with change of OID as a result. It would be
>>>>devastating if we can't update a QCP because that would force an OID 
>>>>update
>>>>and that would render certificates useless because clients learned to
>>>>recognize only the old OID. This would be to build in a new root
>>>>certificate problem into the platforms.
>>>>My observations is that times have changed. I have seen clear indications
>>>>that market players want, and even require for interoperability reasons,
>>>>that use QCStatements solution is made mandatory and maybe even critical
>>>>for QC.
>>>>Since both RFC 3039, and TS 101862 are up for revision, it is time to
>>>>revisit this issue.
>>>>I have some questions and proposals:
>>>>- Is there any experiences of this issue outside of Europe. I.e. are there
>>>>other legal systems that make use of the same declaration logic as the EU
>>>>directive, where the RFC 3039 profile is used fully or partly as a 
>>>>solution
>>>>to this issue?
>>>>- I would suggest that the QCStatement mechanism is ought to be a 
>>>>mandatory
>>>>tool to communicate a Qualified Status. The question is:
>>>>     1) whether this will have enough implementation support to succeed?
>>>>     2) whether is best specified in RFC 3039 or in local profiles 
>>>> (such as
>>>>TS 101862)?
>>>>     3) If there could be a clear context defined where criticality 
>>>> could be
>>>>allowed or even required?
>>>>I would really like feedback from practical experiences from this 
>>>>issue, as
>>>>well as constructive proposals.
>>>>/Stefan
>>>>
>>>>
>>>>/Stefan
>>>>
>>>>_____________________________
>>>>Stefan Santesson,  Retrospekt AB
>>>>http://www.retrospekt.com
>>>>+46-706 443351
>>>_____________________________
>>>Stefan Santesson,  Retrospekt AB
>>>http://www.retrospekt.com
>>>+46-706 443351
>>
>>_____________________________
>>Stefan Santesson,  Retrospekt AB
>>http://www.retrospekt.com
>>+46-706 443351
>
>_____________________________
>Stefan Santesson,  Retrospekt AB
>http://www.retrospekt.com
>+46-706 443351

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
+46-706 443351

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 17 Mar 2003 16:38:39 +0100

Stefan,

> I've heard many answers but the questions that needs them has not yet 
> ben formulated.

So what is the question for which you already got negative answers ?

:-)

Denis

> 1) Current definition of the qcStatements ext says that if the extension 
> is critical then all statements are critical.
> 
> 2) It is compliant with X.509 to state that if an extension is critical, 
> it is OK to recognize at least 1 of the contained elements. It is 
> however unlikely that this is a good solution for the qcStatements 
> extension, due to legacy and the different nature of different statements.
> 
> time in the future since many local statement could be defined that 
> would not be supported by clients in general.
> 
> Questions:
> 
> b) could any such context be clearly defined and included in RFC 3039bis 
> or any local standard?
> 
> 
> Answers:
> 
> Question a)
> Many has complained about the problem to isolate a particular 
> certificate for use in only electronic signature applications where the 
> content is clearly presented and accepted by the signer prior to 
> signing. The key usage or extended key usage extensions are not ready to 
> provide this functionality. At least not today.
> 
> certificates. But given that there are cases where it is of great value 
> to isolate certificates use to informed applications. Then it might as 
> well be worth the effort to try to formulate one or some clear contexts 
> where setting the extension critical ought to be mandatory OR at least 
> recommended.
> 
> 
> Opinions:
> 
> issue with open minds before we reach a definitive conclusion to answer 
> b). Personally I do believe we have a chance to contribute in a good way 
> to supporting good use and acceptance of electronic signatures and 
> believe that such context could and should be formulated.
> 
> 
> /Stefan
> 
> 
> 
> 
> 
>> that. However, the semantics of the extension dictate the opposite 
>> where ALL statements are critical.
>>
>>     Are you saying that it would have been compliant with X.509 to
>>     declare that a critical QCStatement (disregarding the current
>>     declaration in RFC 3039) is valid if I can process at least one of
>>     the present statements (similar to SubjectAltName).
>>
>>>         I don't want to get off on a non-relevant tangent regarding
>>>         criticality, but think I do need to clarify a little bit on
>>>         the subject Alt Name extension. If you check 8.3.2.3 (509)
>>>         you'll find that the semantics of that extension are such
>>>         that, if set to critical, "at least one of the name forms
>>>         that is present shall be recognized and processed ...". So
>>>         if, in your example, the ONLY name present in subjectAltName
>>>         extension is the unknown otherName OID, then you are correct
>>>         and the certificate shall be considered invalid. If however,
>>>         that unknown otherName OID was present AND and rfc822Name was
>>>         present - the RP might understand the rfc822Name and check it
>>>         against the intended recipient of an encrypted email for
>>>         example, and under those circumstances the certificate would
>>>         be valid, even though the extension was critical and there
>>>         was another nameform in there that was not understood.
>>>          
>>>         I suspect that its probably a bit too soon to profile the
>>>         kind of contexts I think you're describing in 3039. I'd
>>>         prefer to see a bit more practical use of QCs first so that
>>>         we have a better handle on what constitutes a "context". For
>>>         example, perhaps one context is with the ETSI qcstatement 1
>>>         plus a specific national qc statement and if both are present
>>>         in a certificate that some 'authority' (I don't mean a CA
>>>         here) deems that when that combination is present the
>>>         extension shall be set to critical. I'm not necessarily
>>>         opposing the idea, just a little uncomfortable with the
>>>         proposed timing without significant real world deployment to
>>>         guide us with to the appropriate 'contexts'.
>>>          
>>>         Cheers,
>>>         Sharon -----Original Message----- From: Stefan Santesson
>>>         [mailto:[email-masked]] Sent: Tuesday, March 11, 2003
>>>         4:06 PM To: Sharon Boeyen; Sharon Boeyen; [email-masked]
>>>         Sharon, Thanks for the clarification.
>>>         So it is OK to accept an certificate with a critical policy
>>>         extension containing an policy OID that I don't recognize,
>>>         because it doesn't define any further syntax of the
>>>         extension. The same goes with Extended key usage OIDs.
>>>         However. It would not be OK with a critical subjectAltName
>>>         containing an unknown other name OID, since this OID would
>>>         define further syntax. By the same reason I would need to
>>>         understand all present QCStatements OIDs, because they do the
>>>         same (define further syntax).
>>>         Let me clarify that I never proposed that the QCStatement
>>>         must be critical in all certificates. I'm just recognizing
>>>         that it might be a valuable practice within certain contexts
>>>         and the fact that some implementers actually ask for it. The
>>>         question is whether any of those contexts can be identified
>>>         within RFC 3039, or if they are better placed in local
>>>         sub-profiles (Such as ETSI TS 101862), or if they don't exist
>>>         in a way that can be standardized in a meaningful way.
>>>
>>>         /Stefan
>>>
>>>>               Remember first that RFC 3280 is a "profile" of X.509
>>>>             and it does not replace the requirements of 509, but
>>>>             rather profiles them to a subset.
>>>>               X.509 in clause 7 allows unknown elements in
>>>>             non-critical extensions only to be ignored. However,
>>>>             that is more with respect to the elements in the syntax
>>>>             itself (for example in the IDP extension no RP is
>>>>             allowed to ignore the "onlySomeReasons" element if it is
>>>>             present in the extension because the extension can only
>>>>             be critical. The behaviour of RPs will differ however
>>>>             depending on their specific capability with respect to
>>>>             that element (some will use the CRL for the specified
>>>>             reasons and others will seek a different CRL that covers
>>>>             all reasons), however, no RP is permitted to simply
>>>>             ignore the flag. Note also that in that same clause, for
>>>>             extensions that can be marked critical or non-critical,
>>>>             a system that understands the extension is required to
>>>>             process it regardless of the value of the criticality
>>>>             flag. It is ONLY systems that do not understand an
>>>>             extension that can ignore it completely if it is marked
>>>>             non-critical.
>>>>               For the QC Statements extension, RFC 3039 says "This
>>>>             extension may be critical or non-critical.  If the
>>>>             extension is critical, this means that all statements
>>>>               Because of the semantics defined for the extension in
>>>>             RFC 3039, marking it critical would result in the
>>>>             problems I raised.
>>>>
>>>>             -----Original Message----- From: Stefan Santesson
>>>>             [mailto:[email-masked]] Sent: Tuesday, March 11,
>>>>             2003 11:23 AM To: Sharon Boeyen; [email-masked]
>>>>             Hi Sharon, My interpretation of criticality does not
>>>>             really match yours. The only guidance on the meaning of
>>>>             criticality in RFC 3280 (section 4.2) that I can find is:
>>>>
>>>>
>>>>
>>>>
>>>>             My interpretation is that it is OK to accept a
>>>>             certificate if you recognize the extension as such. You
>>>>             don't need to understand ALL information that the
>>>>             extension contains. It seam vital to agree on this issue
>>>>             before we can make any conclusion on QCStatament
>>>>             criticality. /Stefan
>>>>>                 Hi Stefan, While I believe that in the longer term
>>>>>                 certificate policies will be the optimum way to
>>>>>                 convey the necessary information, I acknowledge
>>>>>                 that QC Statements is the more popular scheme at
>>>>>                 present. Therefore I wouldn't have any problem
>>>>>                 should this extension be mandated in RFC 3039.
>>>>>                 However, forcing its criticality is going too far I
>>>>>                 believe. There is an important difference between
>>>>>                 critical and non-critical extensions that we need
>>>>>                 to keep in mind from the relying party's
>>>>>                 perspective. If there is a non-critical extension
>>>>>                 that the RP understands, but that extension
>>>>>                 includes some elements that it does not, then the
>>>>>                 RP is free to process the parts it does understand
>>>>>                 and ignore others. If an extension is critical
>>>>>                 however, the RP is required to understand ALL
>>>>>                 elements within the extension. Where I think this
>>>>>                 can become a problem is the content of the QC
>>>>>                 Statements extension. Note that RFC 3039 and the
>>>>>                 ETSI profile define DIFFERENT statements for
>>>>>                 inclusion in the extension. Also additional
>>>>>                 profiles may add their own local statements and
>>>>>                 even narrower statements can get added in specific
>>>>>                 deployment environments. While the cert issuer may
>>>>>                 want to include many of these statements to enable
>>>>>                 the cert to be used in various environments, the RP
>>>>>                 should only be required to understand and process
>>>>>                 the statements that are appropriate to its own
>>>>>                 operating environment as dictated by its local
>>>>>                 security policy (which could be different than that
>>>>>                 under which the CA operated). Therefore I think
>>>>>                 requiring it to be critical is risky. Also
>>>>>                 requiring that it always be critical would have
>>>>>                 interop/backward compatibility issues. Cheers, Sharon
>>>>>
>>>>>
>>>>>                 -----Original Message----- From: Stefan Santesson
>>>>>                 [mailto:[email-masked]] Sent: Tuesday, March
>>>>>                 11, 2003 8:27 AM To: [email-masked] Subject: QC
>>>>>                 Declaration
>>>>>
>>>>>                 The EU directive introduced a requirement on each
>>>>>                 CA, issuing QC (Qualified Certificates), to clearly
>>>>>                 indicate in these certificate that they are issued
>>>>>                 as QC. ETSI implemented RFC 3039 in relation to the
>>>>>                 European electronic signature directive through
>>>>>                 their Technical Standard (TS 101862) TS 101862
>>>>>                 specified 2 alternative ways to declare a
>>>>>                 certificate as QC. 1) By inclusion of a
>>>>>                 QCStatements extension 2) By including a
>>>>>                 certificate policy identifying this property Even
>>>>>                 though solution number 1) is far easier to handle
>>>>>                 by applications, since they don't need to recognize
>>>>>                 specific QC Policies, ETSI didn't make solution 1)
>>>>>                 mandatory or even consider making it critical, due
>>>>>                 to lack of confidence that clients would widely
>>>>>                 deploy this solution. ETSI needed to define a
>>>>>                 solution that could work even if no one choose to
>>>>>                 implement the new extensions provided by RFC 3039.
>>>>>                 However, It is not feasible to keep clients updated
>>>>>                 over time with different QC policies and even those
>>>>>                 policies that are regarded standardized may be
>>>>>                 updated with change of OID as a result. It would be
>>>>>                 devastating if we can't update a QCP because that
>>>>>                 would force an OID update and that would render
>>>>>                 certificates useless because clients learned to
>>>>>                 recognize only the old OID. This would be to build
>>>>>                 in a new root certificate problem into the
>>>>>                 platforms. My observations is that times have
>>>>>                 changed. I have seen clear indications that market
>>>>>                 players want, and even require for interoperability
>>>>>                 reasons, that use QCStatements solution is made
>>>>>                 mandatory and maybe even critical for QC. Since
>>>>>                 both RFC 3039, and TS 101862 are up for revision,
>>>>>                 it is time to revisit this issue. I have some
>>>>>                 questions and proposals: - Is there any experiences
>>>>>                 of this issue outside of Europe. I.e. are there
>>>>>                 other legal systems that make use of the same
>>>>>                 declaration logic as the EU directive, where the
>>>>>                 RFC 3039 profile is used fully or partly as a
>>>>>                 solution to this issue? - I would suggest that the
>>>>>                 QCStatement mechanism is ought to be a mandatory
>>>>>                 tool to communicate a Qualified Status. The
>>>>>                 question is:     1) whether this will have enough
>>>>>                 implementation support to succeed?     2) whether
>>>>>                 is best specified in RFC 3039 or in local profiles
>>>>>                 (such as TS 101862)?     3) If there could be a
>>>>>                 clear context defined where criticality could be
>>>>>                 allowed or even required? I would really like
>>>>>                 feedback from practical experiences from this
>>>>>                 issue, as well as constructive proposals. /Stefan
>>>>>
>>>>>
>>>>>                 /Stefan
>>>>>
>>>>>                 _____________________________ Stefan Santesson, 
>>>>>                 Retrospekt AB http://www.retrospekt.com
>>>>>             <http://www.retrospekt.com/> +46-706 443351 
>>>>
>>>>             _____________________________ Stefan Santesson, 
>>>>             Retrospekt AB http://www.retrospekt.com
>>>>         <http://www.retrospekt.com/> +46-706 443351 
>>>
>>
>> http://www.retrospekt.com <http://www.retrospekt.com/>
>> +46-706 443351 
> 
> 
> http://www.retrospekt.com <http://www.retrospekt.com/>
> +46-706 443351
> 
> http://www.retrospekt.com <http://www.retrospekt.com/>
> +46-706 443351
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 17 Mar 2003 22:00:56 +0100

I'm not sure what trouble you have but let me help you find them. They are 
right there in the text:

Questions:

/Stefan

At 16:38 2003-03-17 +0100, Denis Pinkas wrote:

>>it is OK to recognize at least 1 of the contained elements. It is however 
>>>>>>                 _____________________________ Stefan 
>>>>>> Santesson,                 Retrospekt AB http://www.retrospekt.com
>>>>>             _____________________________ Stefan 
>>>>> Santesson,             Retrospekt AB http://www.retrospekt.com