Subject: I-D ACTION:draft-ietf-smime-3851bis-04.txt

From: [email-masked]
Date: Tue, 1 Jul 2008 10:15:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification
	Author(s)	: B. Ramsdell, S. Turner
	Filename	: draft-ietf-smime-3851bis-04.txt
	Pages		: 46
	Date		: 2008-7-1
	
This document defines Secure/Multipurpose Internet Mail Extensions 
   (S/MIME) version 3.2.  S/MIME provides a consistent way to send and 
   receive secure MIME data.  Digital signatures provide authentication, 
   message integrity, and non-repudiation with proof of origin. 
   Encryption provides data confidentiality.  Compression can be used to 
   reduce data size.  This document obsoletes RFC 3851.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-3851bis-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 28 Jul 2008 14:17:14 +0100

Comments on the draft:

1.  We are not currently making any support statements for DSA w/ the
SHA-256 hash algorithms.  Should we be doing so?

2.  For key size support, key of L>1024 are not supported for DSA-SHA-1.

3.  I would like to add the following text to the table.

Key size > 4096   MAY NOT (See security considerations on large keys)

This would finish the table entry out and also reference the discussion on
why very large keys are not recommended.  It is possible that MAY NOT is not
currently valid 2119 language.  In this case I would be happy with ether MAY
or SHOULD NOT.  I would not be happy with MUST NOT.

Jim

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 28 Jul 2008 18:53:03 +0100

>-----Original Message-----
>From: Blake Ramsdell [mailto:[email-masked]] 
>
>On Mon, Jul 28, 2008 at 6:17 AM, Jim Schaad 
><[email-masked]> wrote:
>Unless it's a SHOULD+, no.

I asked at least once if anybody wanted it and there was no response.  I
think unless somebody actually says "yes I want it" we ought to leave it
out.

>> This would finish the table entry out and also reference the 
>> discussion on why very large keys are not recommended.  It 
>is possible 
>> that MAY NOT is not currently valid 2119 language.  In this case I 
>> would be happy with ether MAY or SHOULD NOT.  I would not be 
>happy with MUST NOT.
>
>MAY or SHOULD NOT it is. I would lean towards MAY.

I was leaning towards MAY, but maybe SHOULD NOT is better since the NOT
provides more information on which way we're leaning.  What do others think?

spt

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 31 Jul 2008 16:43:54 +0100

Sean,

I really feel that we need to have two MUST signature algorithms for safety.
When ECC signatures where present that was fine.  Without having the ECC
signature algorithms we really must have one of the DSA algorithms as a must

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Turner, Sean P.
> Sent: Monday, July 28, 2008 6:53 PM
> To: 'Blake Ramsdell'; 'Jim Schaad'
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
> 
> 

From: "Jim Schaad" <[email-masked]>
To: "'Turner, Sean P.'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Thu, 31 Jul 2008 16:43:54 +0100
Sender: [email-masked]

Sean,

I really feel that we need to have two MUST signature algorithms for safety.
When ECC signatures where present that was fine.  Without having the ECC
signature algorithms we really must have one of the DSA algorithms as a must

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Turner, Sean P.
> Sent: Monday, July 28, 2008 6:53 PM
> To: 'Blake Ramsdell'; 'Jim Schaad'
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
> 
> 

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: S/MIME WG Summary
Date: Thu, 31 Jul 2008 13:35:58 +0100
Organization: IECA, Inc.
Sender: [email-masked]

The S/MIME WG did not meeting in Dublin but it's still an active WG.  Here's
what's happening:

- The CMS Symmetric Key Management and Distribution RFC was published as an
RFC after 5+ years in the RFC editor queue!

- The Multiple Signatures in S/MIME ID made its way to the RFC editor.

- An IETF LC was issued for the RSA-KEM ID and comments were received
through the GENART and SECDIR review process.  Resolution of the comments
doesn't seem to be difficult.

- The SHA2 Algs with CMS ID is with the AD.

- A solution to the discuss comment from the IESG on the IBE CMS draft has
been accepted. The IBE architecture ID will be updated shortly and both will
the handed to the AD for new IETF LC (information track). The AD felt the
new LC was required because of change in the IPR statement.

- Three versions of both S/MIME MSG and S/MIME CERT were published.  Text
being tweaked relates to algorithm choices, key sizes, S/MIME v2 to Historic
status, updating media types registrations, and security considerations.

- Two more versions of the RFC3278Update were produced before the document
was converted to a 3279bis and then two more versions were produced. Thanks
to Alfred Hoenes for his timely and thorough reviews.  The remaining issue
with this ID is to align the '02 ASN.1 module with the syntax specified in
the New ASN.1 for CMS and S/MIME ID.

- One version of the New ASN.1 for CMS and S/MIME ID was published.  The
issues that need to be addressed are similar to those facing the New ASN.1
for PKIX ID.  See Jim's slides from the PKIX session for more information.
Note review is requested!

Cheers,

spt

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
Date: Mon, 28 Jul 2008 21:18:29 +0100
Organization: IECA, Inc.
Sender: [email-masked]

Other things Jim requested offline:
 - Point to PKIXALG as opposed to CMSALG, which makes sense since this is
the CERT ID.
 - Add back in changes from v3 to v3.1, which also makes sense because the
section should not have been removed.

spt
>From: Jim Schaad [mailto:[email-masked]] 
>Sent: Monday, July 28, 2008 2:43 PM
>To: Sean P. Turner; 'Blake Ramsdell'
>Cc: [email-masked]
>Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
>
>Comments on the draft.
>
>In section 4.4.3, I find the following text confusing:
>
>End-entity certificates contain an extension that 
>   constrains the certificate from being an issuing authority 
>   certificate (see Section 4.4.2). 
>
>
>I believe that this text might be better as it clarifies what 
>is being stated.  I.e. it is not the fact that basic 
>constraints is being used which actually does the mentioned constraint.
>
>
>End-entity certificates contain the Key Usage extension which 
>restraints the end-entity from using the key to perform 
>issuing authority operations (see
>4.4.4)
>
>Also the previous comment (on 3851bis) on key sizes > 4096 
>should be applied to this document
>
>jim
>
>> From: [email-masked] [mailto:owner-ietf- 
>> [email-masked]] On Behalf Of [email-masked]
>> Sent: Tuesday, July 01, 2008 1:30 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt
>> 
>> This draft is a work item of the S/MIME Mail Security 
>Working Group of 
>> the IETF.
>> 
>> 	Title		: Secure/Multipurpose Internet Mail Extensions
>> (S/MIME) Version 3.2 Certificate Handling
>> 	Author(s)	: S. Turner, B. Ramsdell
>> 	Filename	: draft-ietf-smime-3850bis-04.txt
>> 	Pages		: 20
>> 	Date		: 2008-6-30
>> 
>> This document specifies conventions for X.509 certificate usage by
>>    Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.
>> S/MIME
>>    provides a method to send and receive secure MIME messages, and
>>    certificates are an integral part of S/MIME agent processing.
>> S/MIME agents validate certificates as described in RFC 3280bis, the
>>    Internet X.509 Public Key Infrastructure Certificate and CRL 
>> Profile.
>>    S/MIME agents must meet the certificate processing requirements in
>>    this document as well as those in RFC 3280bis. This document
>>    obsoletes RFC 3850.
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt
>> 

From: "Turner, Sean P." <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "'Jim Schaad'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
Date: Mon, 28 Jul 2008 18:53:03 +0100
Organization: IECA, Inc.
Sender: [email-masked]

spt

From: "Jim Schaad" <[email-masked]>
To: "'Jim Schaad'" <[email-masked]>, "'Sean P. Turner'" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
Date: Mon, 28 Jul 2008 16:05:16 +0100
Sender: [email-masked]

I got some section numbers wrong in typing.

The text in question is in section 4.4.1,
The reference in the new text should still be to section 4.4.2

Jim

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Jim Schaad
> Sent: Monday, July 28, 2008 2:43 PM
> To: Sean P. Turner; 'Blake Ramsdell'
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt
> 
> 
> Comments on the draft.
> 
> In section 4.4.3, I find the following text confusing:
> 
> End-entity certificates contain an extension that
>    constrains the certificate from being an issuing authority
>    certificate (see Section 4.4.2).
> 
> 
> I believe that this text might be better as it clarifies what is being
> stated.  I.e. it is not the fact that basic constraints is being used
> which
> actually does the mentioned constraint.
> 
> 
> End-entity certificates contain the Key Usage extension which
> restraints the
> end-entity from using the key to perform issuing authority operations
> (see
> 4.4.4)
> 
> Also the previous comment (on 3851bis) on key sizes > 4096 should be
> applied
> to this document
> 
> jim
> 
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of [email-masked]
> > Sent: Tuesday, July 01, 2008 1:30 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt
> >
> > This draft is a work item of the S/MIME Mail Security Working Group
> of
> > the IETF.
> >
> > 	Title		: Secure/Multipurpose Internet Mail Extensions
> > (S/MIME) Version 3.2 Certificate Handling
> > 	Author(s)	: S. Turner, B. Ramsdell
> > 	Filename	: draft-ietf-smime-3850bis-04.txt
> > 	Pages		: 20
> > 	Date		: 2008-6-30
> >
> > This document specifies conventions for X.509 certificate usage by
> >    Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.
> > S/MIME
> >    provides a method to send and receive secure MIME messages, and
> >    certificates are an integral part of S/MIME agent processing.
> > S/MIME agents validate certificates as described in RFC 3280bis, the
> >    Internet X.509 Public Key Infrastructure Certificate and CRL
> > Profile.
> >    S/MIME agents must meet the certificate processing requirements in
> >    this document as well as those in RFC 3280bis. This document
> >    obsoletes RFC 3850.
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt
> >

From: "Jim Schaad" <[email-masked]>
To: "Sean P. Turner" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3850bis-04.txt 
Date: Mon, 28 Jul 2008 14:43:00 +0100
Sender: [email-masked]

Comments on the draft.

In section 4.4.3, I find the following text confusing:

End-entity certificates contain an extension that 
   constrains the certificate from being an issuing authority 
   certificate (see Section 4.4.2). 

I believe that this text might be better as it clarifies what is being
stated.  I.e. it is not the fact that basic constraints is being used which
actually does the mentioned constraint.

End-entity certificates contain the Key Usage extension which restraints the
end-entity from using the key to perform issuing authority operations (see
4.4.4)

Also the previous comment (on 3851bis) on key sizes > 4096 should be applied
to this document

jim

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Tuesday, July 01, 2008 1:30 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-smime-3850bis-04.txt
> 
> 	Title		: Secure/Multipurpose Internet Mail Extensions
> (S/MIME) Version 3.2 Certificate Handling
> 	Author(s)	: S. Turner, B. Ramsdell
> 	Filename	: draft-ietf-smime-3850bis-04.txt
> 	Pages		: 20
> 	Date		: 2008-6-30
> 
> This document specifies conventions for X.509 certificate usage by
>    Secure/Multipurpose Internet Mail Extensions (S/MIME) agents.
> S/MIME
>    provides a method to send and receive secure MIME messages, and
>    certificates are an integral part of S/MIME agent processing.
> S/MIME agents validate certificates as described in RFC 3280bis, the
>    Internet X.509 Public Key Infrastructure Certificate and CRL
> Profile.
>    S/MIME agents must meet the certificate processing requirements in
>    this document as well as those in RFC 3280bis. This document
>    obsoletes RFC 3850.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-smime-3850bis-04.txt
> 

From: "Jim Schaad" <[email-masked]>
To: "Sean P. Turner" <[email-masked]>, "'Blake Ramsdell'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt 
Date: Mon, 28 Jul 2008 14:17:14 +0100
Sender: [email-masked]

Comments on the draft:

Jim

Date: Mon, 14 Jul 2008 21:26:42 +0100
From: Dr Stephen Henson <[email-masked]>
To: Eric Rescorla <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Algorithm Identifiers in sip-sec-flows
Sender: [email-masked]

Eric Rescorla wrote:
> At Mon, 14 Jul 2008 19:37:36 +0100,
> Dr Stephen Henson wrote:
>>
>> The very recently added CMS code omits the parameters for sha1 and sha2 
>> algorithms and encodes them as NULL for others.
> 
> Has this stuff been released yet?
> 

The documentation and full functionality is present in the development 
version (which will be 0.9.9).

A slightly less functional version has been backported to 0.9.8 and 
first appears in the 0.9.8h release. It has to be specifically enabled 
using "enable-cms" at configuration time. Though a 0.9.8h bug means it 
is advisable to use the latest 0.9.8-stable snapshot.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Date: Mon, 14 Jul 2008 11:50:13 -0700
From: Blake Ramsdell <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Algorithm Identifiers in sip-sec-flows
Sender: [email-masked]

On Mon, Jul 14, 2008 at 11:16:58AM -0700, Eric Rescorla wrote:
>    Implementations SHOULD generate SHA-1
>    AlgorithmIdentifiers with absent parameters.
...
> However, as far as I can tell OpenSSL currently generates the encoding
> with NULL rather than absent, and my memory is that the last time I
> discussed this with the OpenSSL implementors, they weren't interested
> in changing this.
> 
> When we were last working on this a few years ago, I got some message
> from Fluffy saying that we should try to generate an encoding with
> absent regardless. I spent some time patching OpenSSL to make it do
> this, but upon reexamination, it seems kind of lame to have an example
> in the draft that requires some one-off patch to generate, so I
> thought it might be a good idea to get some more advice from the WG.
> I'm not suggesting we change 3370, but is it really necessary to
> have examples which need to be hand-tooled?

>From RFC 2119:

  3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
     may exist valid reasons in particular circumstances to ignore a
     particular item, but the full implications must be understood and
     carefully weighed before choosing a different course.

I say that the OpenSSL implementation emitting NULL and the prevalence of
that implementation constitutes a valid reason in a particular circumstance,
and the full implication is understood (receiving implementations MUST support
NULL). This email exchange constitutes careful weighing before choosing a
different course.

So emit NULL and feel bad about it. You might consider submitting the patch to
OpenSSL anyway though.

Blake

Date: Mon, 14 Jul 2008 11:50:56 -0700
From: Eric Rescorla <[email-masked]>
To: Dr Stephen Henson <[email-masked]>
Cc: Eric Rescorla <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Algorithm Identifiers in sip-sec-flows
Sender: [email-masked]

At Mon, 14 Jul 2008 19:37:36 +0100,
Dr Stephen Henson wrote:
> 
> Eric Rescorla wrote:
> > Robert Sparks and I are trying to finish up draft-ietf-sip-sec-flows
> > (http://tools.ietf.org/html/draft-ietf-sip-sec-flows-01), which
> > contains SIP security exampled and one of the open issues is algorithm
> > identifier encodings.
> > 
> > Like most others, We're using OpenSSL to generate the messages, with
> > RSA with SHA-1 for the signature algorithms. As people will recall,
> > RFC 3370 has this to say about the algorithm identifiers:
> > 
> >    The SHA-1 message digest algorithm is defined in FIPS Pub 180-1
> >    [SHA1].  The algorithm identifier for SHA-1 is:
> > 
> >       sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
> >           oiw(14) secsig(3) algorithm(2) 26 }
> > 
> >    There are two possible encodings for the SHA-1 AlgorithmIdentifier
> >    parameters field.  The two alternatives arise from the fact that when
> >    the 1988 syntax for AlgorithmIdentifier was translated into the 1997
> >    syntax, the OPTIONAL associated with the AlgorithmIdentifier
> >    parameters got lost.  Later the OPTIONAL was recovered via a defect
> >    report, but by then many people thought that algorithm parameters
> >    were mandatory.  Because of this history some implementations encode
> >    parameters as a NULL element and others omit them entirely.  The
> >    correct encoding is to omit the parameters field; however,
> >    implementations MUST also handle a SHA-1 AlgorithmIdentifier
> >    parameters field which contains a NULL.
> > 
> >    The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
> >    the parameters field MUST contain a NULL.  Implementations MUST
> >    accept SHA-1 AlgorithmIdentifiers with absent parameters.
> >    Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL
> >    parameters.  Implementations SHOULD generate SHA-1
> >    AlgorithmIdentifiers with absent parameters.
> > 
> > However, as far as I can tell OpenSSL currently generates the encoding
> > with NULL rather than absent, and my memory is that the last time I
> > discussed this with the OpenSSL implementors, they weren't interested
> > in changing this.
> > 
> > When we were last working on this a few years ago, I got some message
> > from Fluffy saying that we should try to generate an encoding with
> > absent regardless. I spent some time patching OpenSSL to make it do
> > this, but upon reexamination, it seems kind of lame to have an example
> > in the draft that requires some one-off patch to generate, so I
> > thought it might be a good idea to get some more advice from the WG.
> > I'm not suggesting we change 3370, but is it really necessary to
> > have examples which need to be hand-tooled?
> > 
> 
> At the time OpenSSL didn't support CMS only PKCS#7.
> 
> There are a few separate cases which OpenSSL handles.
> 
> The PKCS#1 DigestInfo structure includes NULL. As I recall this is a 
> specific exception partly to cover implementations that process 
> DigestInfo with a cut and paste operations.
> 
> The PKCS#7 code includes NULL. I'd have to check my archives but I can 
> vaguely recall that a compatibility test OpenSSL was put through 
> required this.
> 
> The very recently added CMS code omits the parameters for sha1 and sha2 
> algorithms and encodes them as NULL for others.

Has this stuff been released yet?

Thanks,
-Ekr

Date: Mon, 14 Jul 2008 19:37:36 +0100
From: Dr Stephen Henson <[email-masked]>
To: Eric Rescorla <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Algorithm Identifiers in sip-sec-flows
Sender: [email-masked]

Eric Rescorla wrote:
> Robert Sparks and I are trying to finish up draft-ietf-sip-sec-flows
> (http://tools.ietf.org/html/draft-ietf-sip-sec-flows-01), which
> contains SIP security exampled and one of the open issues is algorithm
> identifier encodings.
> 
> Like most others, We're using OpenSSL to generate the messages, with
> RSA with SHA-1 for the signature algorithms. As people will recall,
> RFC 3370 has this to say about the algorithm identifiers:
> 
>    The SHA-1 message digest algorithm is defined in FIPS Pub 180-1
>    [SHA1].  The algorithm identifier for SHA-1 is:
> 
>       sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
>           oiw(14) secsig(3) algorithm(2) 26 }
> 
>    There are two possible encodings for the SHA-1 AlgorithmIdentifier
>    parameters field.  The two alternatives arise from the fact that when
>    the 1988 syntax for AlgorithmIdentifier was translated into the 1997
>    syntax, the OPTIONAL associated with the AlgorithmIdentifier
>    parameters got lost.  Later the OPTIONAL was recovered via a defect
>    report, but by then many people thought that algorithm parameters
>    were mandatory.  Because of this history some implementations encode
>    parameters as a NULL element and others omit them entirely.  The
>    correct encoding is to omit the parameters field; however,
>    implementations MUST also handle a SHA-1 AlgorithmIdentifier
>    parameters field which contains a NULL.
> 
>    The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
>    the parameters field MUST contain a NULL.  Implementations MUST
>    accept SHA-1 AlgorithmIdentifiers with absent parameters.
>    Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL
>    parameters.  Implementations SHOULD generate SHA-1
>    AlgorithmIdentifiers with absent parameters.
> 
> However, as far as I can tell OpenSSL currently generates the encoding
> with NULL rather than absent, and my memory is that the last time I
> discussed this with the OpenSSL implementors, they weren't interested
> in changing this.
> 
> When we were last working on this a few years ago, I got some message
> from Fluffy saying that we should try to generate an encoding with
> absent regardless. I spent some time patching OpenSSL to make it do
> this, but upon reexamination, it seems kind of lame to have an example
> in the draft that requires some one-off patch to generate, so I
> thought it might be a good idea to get some more advice from the WG.
> I'm not suggesting we change 3370, but is it really necessary to
> have examples which need to be hand-tooled?
> 

At the time OpenSSL didn't support CMS only PKCS#7.

There are a few separate cases which OpenSSL handles.

The PKCS#1 DigestInfo structure includes NULL. As I recall this is a 
specific exception partly to cover implementations that process 
DigestInfo with a cut and paste operations.

The PKCS#7 code includes NULL. I'd have to check my archives but I can 
vaguely recall that a compatibility test OpenSSL was put through 
required this.

The very recently added CMS code omits the parameters for sha1 and sha2 
algorithms and encodes them as NULL for others.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

Date: Mon, 14 Jul 2008 11:16:58 -0700
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Algorithm Identifiers in sip-sec-flows
Sender: [email-masked]

Robert Sparks and I are trying to finish up draft-ietf-sip-sec-flows
(http://tools.ietf.org/html/draft-ietf-sip-sec-flows-01), which
contains SIP security exampled and one of the open issues is algorithm
identifier encodings.

Like most others, We're using OpenSSL to generate the messages, with
RSA with SHA-1 for the signature algorithms. As people will recall,
RFC 3370 has this to say about the algorithm identifiers:

   The SHA-1 message digest algorithm is defined in FIPS Pub 180-1
   [SHA1].  The algorithm identifier for SHA-1 is:

      sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
          oiw(14) secsig(3) algorithm(2) 26 }

   There are two possible encodings for the SHA-1 AlgorithmIdentifier
   parameters field.  The two alternatives arise from the fact that when
   the 1988 syntax for AlgorithmIdentifier was translated into the 1997
   syntax, the OPTIONAL associated with the AlgorithmIdentifier
   parameters got lost.  Later the OPTIONAL was recovered via a defect
   report, but by then many people thought that algorithm parameters
   were mandatory.  Because of this history some implementations encode
   parameters as a NULL element and others omit them entirely.  The
   correct encoding is to omit the parameters field; however,
   implementations MUST also handle a SHA-1 AlgorithmIdentifier
   parameters field which contains a NULL.

   The AlgorithmIdentifier parameters field is OPTIONAL.  If present,
   the parameters field MUST contain a NULL.  Implementations MUST
   accept SHA-1 AlgorithmIdentifiers with absent parameters.
   Implementations MUST accept SHA-1 AlgorithmIdentifiers with NULL
   parameters.  Implementations SHOULD generate SHA-1
   AlgorithmIdentifiers with absent parameters.

However, as far as I can tell OpenSSL currently generates the encoding
with NULL rather than absent, and my memory is that the last time I
discussed this with the OpenSSL implementors, they weren't interested
in changing this.

When we were last working on this a few years ago, I got some message
from Fluffy saying that we should try to generate an encoding with
absent regardless. I spent some time patching OpenSSL to make it do
this, but upon reexamination, it seems kind of lame to have an example
in the draft that requires some one-off patch to generate, so I
thought it might be a good idea to get some more advice from the WG.
I'm not suggesting we change 3370, but is it really necessary to
have examples which need to be hand-tooled?

-Ekr

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt 
Date: Fri, 11 Jul 2008 08:52:32 -0400
Organization: IECA, Inc.
Sender: [email-masked]

Since the S/MIME WG is not meeting in Dublin, the authors of this ID have
indicated to me that they would like to meet with anybody interested in
discussing their ID. Contact either Francesco Gennai
<[email-masked]> or Alba Shahin <[email-masked]>.

spt

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Turner, Sean P.
>Sent: Wednesday, July 02, 2008 4:38 PM
>To: [email-masked]
>Subject: FW: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt 
>
>I'd like to draw attention to this ID.  Alba and Francesco 
>described the PEC (Posta Elettronica Certificata) at IETF 71
>(https://www3.ietf.org/proceedings/08mar/slides/smime-4.pdf) 
>and this is the ID that provides a much more detailed 
>technical description of PEC.  Many at the meeting indicated 
>they were willing to review - so please do and provide 
>comments to the authors.
>
>spt 
>
>From: [email-masked] 
>[mailto:[email-masked]]
>On Behalf Of [email-masked]
>Sent: Monday, June 30, 2008 6:30 PM
>To: [email-masked]
>Subject: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt 
>
>A New Internet-Draft is available from the on-line 
>Internet-Drafts directories.
>
>
>	Title		: Certified Electronic Mail
>	Author(s)	: F. Gennai, A. Shahin, C. Petrucci, A. 
>Vinciarelli
>	Filename	: draft-gennai-smime-cnipa-pec-00.txt
>	Pages		: 62
>	Date		: 2008-6-30
>	
>Since 1997, the Italian Laws have recognized electronic delivery 
>   systems as legally usable. After 2 years of technical tests, in 
>   2005 the characteristics of an official electronic delivery 
>   service, named certified electronic mail (in Italian "Posta 
>   Elettronica Certificata") were defined, giving the system legal 
>   value.  
>
>   Design of the entire system was carried out by the National 
>   Center for Informatics in the Public Administration of Italy 
>   (CNIPA), followed by efforts for the implementation and testing 
>   of the service. The CNIPA has given the Italian National 
>   Research Council (CNR), and in particular The Institute of 
>   Information Science and Technologies at the CNR (ISTI), the task 
>   to run tests on providers of the service to guarantee the 
>   correct implementation and interoperability.This document 
>   describes the certified email system adopted in Italy. It 
>   represents the system as it is at the moment of writing, 
>   following the technical regulations that were written based upon 
>   the Italian Law DPR. November 2, 2005. 
>
>http://www.ietf.org/internet-drafts/draft-gennai-smime-cnipa-pec-00.txt
>
>Below is the data which will enable a MIME compliant mail 
>reader implementation to automatically retrieve the ASCII 
>version of the Internet-Draft.
>

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-smime-new-asn1-01.txt 
Date: Thu, 10 Jul 2008 10:15:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title           : New ASN.1 Modules for CMS and S/MIME
	Author(s)       : P. Hoffman, J. Schaad
	Filename        : draft-ietf-smime-new-asn1-01.txt
	Pages           : 56
	Date            : 2008-07-10

The Cryptographic Message Syntax (CMS) format, and many associated
formats, are expressed using ASN.1.  The current ASN.1 modules
conform to the 1988 version of ASN.1.  This document updates those
ASN.1 modules to conform to the 2002 version of ASN.1.  There are no
bits-on-the-wire changes to any of the formats; this is simply a
change to the syntax.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-new-asn1-01.txt

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-new-asn1-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <[email-masked]>

--NextPart--

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: IPR # 896
Date: Wed, 9 Jul 2008 16:09:33 -0400
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0152_01C8E1DE.2D2B7070
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

FYI

https://datatracker.ietf.org/ipr/896/

------=_NextPart_000_0152_01C8E1DE.2D2B7070
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>IPR # 896</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">FYI</FONT>
</P>

<P><A HREF=3D"https://datatracker.ietf.org/ipr/896/"><U><FONT =
COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">https://datatracker.ietf.org/ipr/896/</FONT></U></A>
</P>

</BODY>
</HTML>
------=_NextPart_000_0152_01C8E1DE.2D2B7070--

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Using Signature Policy in RFC-5126
Date: Fri, 04 Jul 2008 16:54:54 +1200
Sender: [email-masked]

"Pavel V. Smirnov" <[email-masked]> writes:

>Julien mentioned a point considered in Note 3: "Unless DER is used
>throughout, it is recommended that the binary encoding of the ASN.1
>structures being time-stamped be preserved when being archived to ensure
>that the recalculation of the data hash is consistent".

Oh, I'm surprised this isn't the default for everything - are implementors 
really trying to decode and re-encode data and expecting the signature to 
still validate?  Doing this violates the primary enoding rule, "There is only 
one (re-)encoding mechanism and memcpy() is its name".

Peter.

From: "Pavel V. Smirnov" <[email-masked]>
To: "'Yasir Khan'" <[email-masked]>, <[email-masked]>
Subject: RE: Using Signature Policy in RFC-5126
Date: Fri, 4 Jul 2008 08:32:23 +0400
Sender: [email-masked]

------=_NextPart_000_003D_01C8DDB0.7CB2BBD0
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

There are a couple of notes regarding archive timestamp that could help =
you.

=20

Note 4 says: "The hash is calculated over the concatenated data elements =
as
received/stored, including the Type and Length encoding".

=20

Julien mentioned a point considered in Note 3: "Unless DER is used
throughout, it is recommended that the binary encoding of the ASN.1
structures being time-stamped be preserved when being archived to ensure
that the recalculation of the data hash is consistent".

=20

So. To simplify your implementation you should use DER encoding =
everywhere
or just always keep original binary encoding. After that you have to
concatenate binary representations of all the fields listed not trying =
to
throw away Type and Length tags, or getting all certificates or crls =
from
Certificates or crls elements of SignedData and concatenating them. Just
concatenate full binary encodings of the listed elements in the =
mentioned
order. But you have to turn over a SignerInfo sequence: you should not
include outer SignerInfo Type and Length tags in hashing, but rather =
include
every element of SignerInfo starting from version and finising with
unsignedAttrs.

=20

Said above is enough to add an archive timestamp attribute. Concerning
verifying of this timestamp you should do the same concatenation, but =
throw
away all archive timestamps with time later then in the timestamp being
verified from unsignedAttrs element and encode it over again.

=20

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

=20

From: Yasir Khan [mailto:[email-masked]]=20
Sent: Thursday, July 03, 2008 8:07 PM
To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC =
=F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

=20

RFC 5126 explains how to create archived time stamp i.e.

=20

=20

ArchiveTimeStampToken ::=3D TimeStampToken

=20

   The value of the messageImprint field within TimeStampToken shall be

   a hash of the concatenation of:

=20

      - the encapContentInfo element of the SignedData sequence;

=20

      - any external content being protected by the signature, if the

        eContent element of the encapContentInfo is omitted;

=20

      - the Certificates and crls elements of the SignedData sequence,

        when present, and;

=20

      - all data elements in the SignerInfo sequence including all

        signed and unsigned attributes.

 =20

=20

The ArchiveTimeStamp will be added as an unsigned attribute in the
SignerInfo sequence.

=20

According to the RFC, it is clear that message imprint will be the hash =
of
above concatenated values but it is not explained how to concatenate =
these
values? Please clarify this point. Some hint for implementing this would =
be
highly appreciated. Thanks!

=20

-------------------------------------------------------------------------=
---
------

YASIR KHAN
Development Manager

=20

Ascertia Limited
 <http://www.ascertia.com/> www.ascertia.com  =20

www.globaltrustfinder.com <http://www.globaltrustfinder.com/> =20

-------------------------------------------------------------------------=
---
------

Delivering Trust for e-business Documents & Workflows

-------------------------------------------------------------------------=
---
------

NOTICE: This message is intended for the recipient(s) only. This
communication may contain privileged or other

confidential information. If you are not the intended recipient, or =
believe
that you have received this communication in

error, please do not print, copy, retransmit, disseminate, or otherwise =
use
the information. Please notify the sender that

you have received this email in error, and delete the copy you received

=20

  _____ =20

From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of Pavel V. Smirnov
Sent: Thursday, June 26, 2008 1:04 PM
To: 'Yasir Khan'; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

=20

Yes, I mean "digital signature policy" as a "policy document" present at
SPUri. But I use SPUri only for example, you may specify a SigPolicyId =
and
omit sigPolicyQualifiers at all. In this case you have to rely on some =
other
means to convey a correspondence between SigPolicyIds and "policy
documents".

=20

In case of SPuri you have to retrieve a "policy document" by its URI and
hash it.

=20

Note that if your infrastructure provides a trusted source of "policy
documents", and there will never be two different (versions of) "policy
documents" identified by the same OID, you don't have to hash them at =
all.
Just use zero policy hash value.

=20

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

=20

From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of Yasir Khan
Sent: Thursday, June 26, 2008 12:19 PM
To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC =
=F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

=20

You wrote: "You have to hash a digital signature policy represented as a
sequence of bytes in some format and place the computed value in
SigPolicyHash."

=20

To which item you are naming as "digital signature policy". You mean =
policy
document present at SPUri? If Yes then it makes some sense. But if only
SPUserNotice is present or nothing is present as sigPolicyQualifiers as =
it
is an OPTIONAL element:

=20

            sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL

=20

then on which item the hash would be computed?

=20

Regards,

Yasir Khan

=20

=20

  _____ =20

From: Pavel V. Smirnov [mailto:[email-masked]]=20
Sent: Wednesday, June 25, 2008 4:07 PM
To: 'Yasir Khan'; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

=20

Hello Yasir,

=20

There is no need to protect by SigPolicyHash other fields of
SignaturePolicyId structure because it is placed in a signed attribute. =
All
signed attributes are protected by the signature itself.

=20

In most cases the policy would be an external document not included in =
your
signed message, and you have to unambiguously indicate specific policy =
with
respect to which your document should be treated. E.g., you may only =
have an
URI pointing to the policy as a SigPolicyQualifier.

=20

You have to hash a digital signature policy represented as a sequence of
bytes in some format and place the computed value in SigPolicyHash.

=20

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

=20

From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of Yasir Khan
Sent: Wednesday, June 25, 2008 2:43 PM
To: [email-masked]
Subject: Using Signature Policy in RFC-5126

=20

We have a question related to using the signature policy in the CAdES
signatures (EPES) defined in RFC-5126. Here is the relevant structure:

=20

SignaturePolicyId ::=3D SEQUENCE {

            sigPolicyIdentifier SigPolicyId,

            sigPolicyHash SigPolicyHash,

            sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF

            SigPolicyQualifierInfo OPTIONAL

}

=20

SigPolicyId ::=3D OBJECT IDENTIFIER

=20

SigPolicyHash ::=3D OtherHashAlgAndValue

=20

OtherHashAlgAndValue ::=3D SEQUENCE {

            hashAlgorithm   AlgorithmIdentifier,

        hashValue       OtherHashValue=20

}

=20

SigPolicyQualifierInfo ::=3D SEQUENCE {

            sigPolicyQualifierId SigPolicyQualifierId,

            sigQualifier ANY DEFINED BY sigPolicyQualifierId

}

=20

SigPolicyQualifierId ::=3D OBJECT IDENTIFIER

id-spq-ets-uri OBJECT IDENTIFIER ::=3D {=20

            iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) =
pkcs9(9)
smime(16) id-spq(5) 1=20

}

SPuri ::=3D IA5String

=20

id-spq-ets-unotice OBJECT IDENTIFIER ::=3D {=20

            iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) =
pkcs9(9)
smime(16) id-spq(5) 2=20

}

SPUserNotice ::=3D SEQUENCE {

            noticeRef NoticeReference OPTIONAL,

            explicitText DisplayText OPTIONAL

}

=20

NoticeReference ::=3D SEQUENCE {

            organization DisplayText,

            noticeNumbers SEQUENCE OF INTEGER

}

=20

DisplayText ::=3D CHOICE {

            visibleString VisibleString (SIZE (1..200)),

            bmpString BMPString (SIZE (1..200)),

            utf8String UTF8String (SIZE (1..200))

}

=20

In the given structure for CAdES-EPES signature, its is not clear that
whether are we computing the hash "SigPolicyHash" over the document at
"SPuri" and/or over the "SPUserNotice"

=20

Are the following combinations valid?

=20

1) Only compute hash over document present at SPURI if only SPUri is set =

2) Only compute hash over SPUserNotice  if only SPUserNotice is set

3) Compute hash over document at SPURI and SPUserNotice if both are set

=20

Please clarify it. Thanks!

=20

Regards,

=20

Yasir Khan
Development Manager

=20

Ascertia Ltd
40 Occam Road=20
Surrey Research Park
Guildford
Surrey, GU2 7YG
United Kingdom

=20

t.  +44 (0)1483 685500
f.  +44 (0)1483 573704=20

=20

www.ascertia.com <http://www.ascertia.com/>    =20

=20

-----------------------------------------------------------------
         Identity Proven, Trust Delivered
-----------------------------------------------------------------

=20

=20

------=_NextPart_000_003D_01C8DDB0.7CB2BBD0
Content-Type: text/html; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dkoi8-r">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal;
	font-family:"Arial","sans-serif";
	color:navy;}
span.EmailStyle24
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DRU link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There are a couple of notes regarding archive timestamp =
that
could help you.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Note 4 says: &#8220;The hash is calculated over the =
concatenated
data elements as received/stored, including the Type and Length =
encoding&#8221;.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Julien mentioned a point considered in Note 3: =
&#8220;Unless DER
is used throughout, it is recommended that the binary encoding of the =
ASN.1
structures being time-stamped be preserved when being archived to ensure =
that
the recalculation of the data hash is =
consistent&#8221;.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So. To simplify your implementation you should use DER =
encoding
everywhere or just always keep original binary encoding. After that you =
have to
concatenate binary representations of all the fields listed not trying =
to throw
away Type and Length tags, or getting all certificates or crls from
Certificates or crls elements of SignedData and concatenating them. Just
concatenate full binary encodings of the listed elements in the =
mentioned
order. But you have to turn over a SignerInfo sequence: you should not =
include
outer SignerInfo Type and Length tags in hashing, but rather include =
every
element of SignerInfo starting from version and finising with =
unsignedAttrs.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Said above is enough to add an archive timestamp =
attribute. Concerning
verifying of this timestamp you should do the same concatenation, but =
throw
away all archive timestamps with time later then in the timestamp being =
verified
from unsignedAttrs element and encode it over =
again.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'>Pavel Smirnov<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'>Crypto-Pro<br>
Tel./Fax: +7 495 780-4820<br>
WWW: </span><span =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'><a href=3D"http://www.cryptopro.ru/" =
title=3D"http://www.cryptopro.ru/"><span
lang=3DEN-US>http://www.CryptoPro.ru</span></a></span><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";color:navy'>=
<br>
e-mail: </span><span =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'><a href=3D"mailto:[email-masked]" =
title=3D"mailto:[email-masked]"><span
lang=3DEN-US>[email-masked]</span></a></span><span lang=3DEN-US =
style=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></spa=
n></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Yasir Khan
[mailto:[email-masked]] <br>
<b>Sent:</b> Thursday, July 03, 2008 8:07 PM<br>
<b>To:</b> =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC =
=F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; [email-masked]<br>
<b>Subject:</b> RE: Using Signature Policy in =
RFC-5126<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>RFC 5126 explains how to create archived time stamp =
i.e.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>ArchiveTimeStampToken ::=3D =
TimeStampToken<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp;&nbsp; The value of the messageImprint field within
TimeStampToken shall be<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp;&nbsp; a hash of the concatenation =
of:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - the encapContentInfo =
element of the
SignedData sequence;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - any external content being
protected by the signature, if the<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; eContent element =
of the
encapContentInfo is omitted;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - the Certificates and crls =
elements
of the SignedData sequence,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; when present, =
and;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - all data elements in the
SignerInfo sequence including all<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; signed and =
unsigned
attributes.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>&nbsp; <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>The ArchiveTimeStamp will be added as an unsigned attribute =
in the
SignerInfo sequence.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>According to the RFC, it is clear that message imprint will =
be the
hash of above concatenated values but it is not explained how to =
concatenate
these values? Please clarify this point. Some hint for implementing this =
would
be highly appreciated. Thanks!<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>-------------=
---------------------------------------------------------------------</sp=
an><span
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><strong><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:navy'>YASIR KHAN</span></strong><b><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'><b=
r>
</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Development
Manager</span><strong><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p></o:p></span></strong></p>

<p class=3DMsoNormal><span lang=3DEN-US>&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal><strong><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:navy'>Ascertia Limited</span></strong><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'><b=
r>
</span><span lang=3DEN-US><a href=3D"http://www.ascertia.com/"
title=3D"blocked::http://www.ascertia.com/"><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'>www.ascertia.com</span></a></span><span=

lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><a
href=3D"http://www.globaltrustfinder.com/">www.globaltrustfinder.com</a> =
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>-------------=
---------------------------------------------------------------------</sp=
an><span
lang=3DEN-US><o:p></o:p></span></p>

<p class=3DMsoNormal><em><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif"'>Delivering Trust for e-business Documents &amp; =
Workflows</span></em><em><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p></o:p></=
span></em></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>-------------=
---------------------------------------------------------------------</sp=
an><o:p></o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:7.5pt;font-family:"Verdana","sans-serif";
color:gray'>NOTICE: This message is intended for the recipient(s) only. =
This
communication may contain privileged or other<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:7.5pt;font-family:"Verdana","sans-serif";
color:gray'>confidential information. If you are not the intended =
recipient, or
believe that you have received this communication =
in<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:7.5pt;font-family:"Verdana","sans-serif";
color:gray'>error, please do not print, copy, retransmit, disseminate, =
or
otherwise use the information. Please notify the sender =
that<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:7.5pt;font-family:"Verdana","sans-serif";
color:gray'>you have received this email in error, and delete the copy =
you
received</span><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p></o:p></=
span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span =
lang=3DEN-US>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</span></div>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Pavel V. =
Smirnov<br>
<b>Sent:</b> Thursday, June 26, 2008 1:04 PM<br>
<b>To:</b> 'Yasir Khan'; [email-masked]<br>
<b>Subject:</b> RE: Using Signature Policy in RFC-5126</span><span =
lang=3DEN-US><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Yes, I mean &#8220;digital signature policy&#8221; as a
&#8220;policy document&#8221; present at SPUri. But I use SPUri only for
example, you may specify a SigPolicyId and omit sigPolicyQualifiers at =
all. In
this case you have to rely on some other means to convey a =
correspondence
between SigPolicyIds and &#8220;policy =
documents&#8221;.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In case of SPuri you have to retrieve a &#8220;policy
document&#8221; by its URI and hash it.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Note that if your infrastructure provides a trusted =
source of
&#8220;policy documents&#8221;, and there will never be two different =
(versions
of) &#8220;policy documents&#8221; identified by the same OID, you =
don&#8217;t
have to hash them at all. Just use zero policy hash =
value.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'>Pavel Smirnov<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'>Crypto-Pro<br>
Tel./Fax: +7 495 780-4820<br>
WWW: </span><span =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'><a href=3D"http://www.cryptopro.ru/" =
title=3D"http://www.cryptopro.ru/"><span
lang=3DEN-US>http://www.CryptoPro.ru</span></a></span><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";color:navy'>=
<br>
e-mail: </span><span =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'><a href=3D"mailto:[email-masked]" =
title=3D"mailto:[email-masked]"><span
lang=3DEN-US>[email-masked]</span></a></span><span lang=3DEN-US =
style=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></spa=
n></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] =
<b>On
Behalf Of </b>Yasir Khan<br>
<b>Sent:</b> Thursday, June 26, 2008 12:19 PM<br>
<b>To:</b> =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC =
=F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; [email-masked]<br>
<b>Subject:</b> RE: Using Signature Policy in =
RFC-5126<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You wrote: &#8221;You have to hash a <b>digital signature =
policy</b>
represented as a sequence of bytes in some format and place the computed =
value
in SigPolicyHash.&#8221;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:navy'>To which item you are naming as &#8220;digital signature
policy&#8221;. You mean policy document present at SPUri? If Yes then it =
makes
some sense. But if only SPUserNotice is present or nothing is present as =
</span><b><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>si=
gPolicyQualifiers</span></b><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> <span
style=3D'color:navy'>as it is an OPTIONAL element</span></span><span =
lang=3DEN-US
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:navy'>=
:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo =
OPTIONAL<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>then on which item the hash would be =
computed?<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'>Yasir Khan<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:navy'><o:p>&nbsp;</o:p></span></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><span =
lang=3DEN-US>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</span></div>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Pavel V. Smirnov =
[mailto:[email-masked]] <br>
<b>Sent:</b> Wednesday, June 25, 2008 4:07 PM<br>
<b>To:</b> 'Yasir Khan'; [email-masked]<br>
<b>Subject:</b> RE: Using Signature Policy in RFC-5126</span><span =
lang=3DEN-US><o:p></o:p></span></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Hello Yasir,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>There is no need to protect by SigPolicyHash other fields =
of
SignaturePolicyId structure because it is placed in a signed attribute. =
All
signed attributes are protected by the signature =
itself.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In most cases the policy would be an external document =
not
included in your signed message, and you have to unambiguously indicate
specific policy with respect to which your document should be treated. =
E.g., you
may only have an URI pointing to the policy as a =
SigPolicyQualifier.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You have to hash a digital signature policy represented =
as a
sequence of bytes in some format and place the computed value in =
SigPolicyHash.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'>Pavel Smirnov<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'>Crypto-Pro<br>
Tel./Fax: +7 495 780-4820<br>
WWW: </span><span =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'><a href=3D"http://www.cryptopro.ru/" =
title=3D"http://www.cryptopro.ru/"><span
lang=3DEN-US>http://www.CryptoPro.ru</span></a></span><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";color:navy'>=
<br>
e-mail: </span><span =
style=3D'font-size:10.0pt;font-family:"Calibri","sans-serif";
color:navy'><a href=3D"mailto:[email-masked]" =
title=3D"mailto:[email-masked]"><span
lang=3DEN-US>[email-masked]</span></a></span><span lang=3DEN-US =
style=3D'font-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></spa=
n></p>

</div>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm =
0cm 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] =
<b>On
Behalf Of </b>Yasir Khan<br>
<b>Sent:</b> Wednesday, June 25, 2008 2:43 PM<br>
<b>To:</b> [email-masked]<br>
<b>Subject:</b> Using Signature Policy in RFC-5126<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>We
have a question related to using the signature policy in the CAdES =
signatures
(EPES) defined in RFC-5126. Here is the relevant =
structure:<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>SignaturePoli=
cyId
::=3D SEQUENCE {<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sigPolicyIdentifier SigPolicyId,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<b>sigPolicyHash SigPolicyHash,<o:p></o:p></b></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
SigPolicyQualifierInfo OPTIONAL<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>}<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>SigPolicyId
::=3D OBJECT IDENTIFIER<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif"'>SigPolicyHash ::=3D =
OtherHashAlgAndValue<o:p></o:p></span></b></p>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></b></p>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif"'>OtherHashAlgAndValue ::=3D SEQUENCE =
{<o:p></o:p></span></b></p>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif"'>&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hashAlgorithm&nbsp;&nbsp;
AlgorithmIdentifier,<o:p></o:p></span></b></p>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
hashValue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OtherHashValue =
<o:p></o:p></span></b></p>

<p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif"'>}<o:p></o:p></span></b></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>SigPolicyQual=
ifierInfo
::=3D SEQUENCE {<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sigPolicyQualifierId SigPolicyQualifierId,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
sigQualifier ANY DEFINED BY sigPolicyQualifierId<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>}<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>SigPolicyQual=
ifierId
::=3D OBJECT IDENTIFIER<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>id-spq-ets-ur=
i
OBJECT IDENTIFIER ::=3D { <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16)
id-spq(5) 1 <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>}<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>SPuri
::=3D IA5String<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>id-spq-ets-un=
otice
OBJECT IDENTIFIER ::=3D { <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16)
id-spq(5) 2 <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>}<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>SPUserNotice
::=3D SEQUENCE {<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
noticeRef NoticeReference OPTIONAL,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
explicitText DisplayText OPTIONAL<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>}<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>NoticeReferen=
ce
::=3D SEQUENCE {<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
organization DisplayText,<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
noticeNumbers SEQUENCE OF INTEGER<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>}<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>DisplayText
::=3D CHOICE {<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
visibleString VisibleString (SIZE (1..200)),<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bmpString BMPString (SIZE (1..200)),<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
utf8String UTF8String (SIZE (1..200))<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>}<o:p></o:p><=
/span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>In
the given structure for CAdES-EPES signature, its is not clear that =
whether are
we computing the hash &quot;SigPolicyHash&quot; over the document at
&quot;SPuri&quot; and/or over the =
&quot;SPUserNotice&quot;<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Are
the following combinations valid?<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>1)
Only compute hash over document present at SPURI if only SPUri is set =
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>2)
Only compute hash over SPUserNotice&nbsp; if only SPUserNotice is =
set<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>3)
Compute hash over document at SPURI and SPUserNotice if both are =
set<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Please
clarify it. Thanks!<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Regards,<o:p>=
</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Yasir
Khan<br>
Development Manager<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Ascertia
Ltd<br>
40 Occam Road <br>
Surrey Research Park<br>
Guildford<br>
Surrey, GU2 7YG<br>
United Kingdom<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>t.&nbsp;
+44 (0)1483 685500<br>
f.&nbsp; +44 (0)1483 573704 <o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><a
href=3D"http://www.ascertia.com/" =
title=3D"blocked::http://www.ascertia.com/">www.ascertia.com</a>&nbsp;&nb=
sp;&nbsp;
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>-------------=
----------------------------------------------------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Identity Proven, Trust
Delivered<br>
-----------------------------------------------------------------<o:p></o=
:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</=
o:p></span></p>

</div>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_000_003D_01C8DDB0.7CB2BBD0--

Date: Thu, 03 Jul 2008 17:27:34 +0200
From: Julien Stern <[email-masked]>
To: Yasir Khan <[email-masked]>
Cc: "'Pavel V. Smirnov'" <[email-masked]>, [email-masked]
Subject: Re: Using Signature Policy in RFC-5126
Sender: [email-masked]

Yasir,

this specific point has caused many interoperability issues. Not only is 
the concatenation method subject to interpretation, but also, if you 
have several archive timestamps, you have to use heuristics to guess the 
previous encoding of the attribute sequence because it can be in BER.

I can give you my humble interpretation of the way to concatenate but I 
cannot promise it will be the same as everyone else.

There are currently discussions regarding a change of this attribute, 
possibly mandating DER encoding to remove all ambiguities. Do you 
believe such a change would be worthwhile ?

Regards,

--
Julien Stern

Yasir Khan wrote:
> RFC 5126 explains how to create archived time stamp i.e.
> 
>  
> 
>  
> 
> ArchiveTimeStampToken ::= TimeStampToken
> 
>  
> 
>    The value of the messageImprint field within TimeStampToken shall be
> 
>    a hash of the concatenation of:
> 
>  
> 
>       - the encapContentInfo element of the SignedData sequence;
> 
>  
> 
>       - any external content being protected by the signature, if the
> 
>         eContent element of the encapContentInfo is omitted;
> 
>  
> 
>       - the Certificates and crls elements of the SignedData sequence,
> 
>         when present, and;
> 
>  
> 
>       - all data elements in the SignerInfo sequence including all
> 
>         signed and unsigned attributes.
> 
>  
> 
>  
> 
> The ArchiveTimeStamp will be added as an unsigned attribute in the 
> SignerInfo sequence.
> 
>  
> 
> According to the RFC, it is clear that message imprint will be the hash 
> of above concatenated values but it is not explained how to concatenate 
> these values? Please clarify this point. Some hint for implementing this 
> would be highly appreciated. Thanks!
> 
>  
> 
> ----------------------------------------------------------------------------------
> 
> **YASIR KHAN***
> *Development Manager****
> 
>  
> 
> **Ascertia Limited**
> www.ascertia.com <http://www.ascertia.com/>  
> 
> www.globaltrustfinder.com <http://www.globaltrustfinder.com/>
> 
> ----------------------------------------------------------------------------------
> 
> //Delivering Trust for e-business Documents & Workflows//
> 
> ----------------------------------------------------------------------------------
> 
> NOTICE: This message is intended for the recipient(s) only. This 
> communication may contain privileged or other
> 
> confidential information. If you are not the intended recipient, or 
> believe that you have received this communication in
> 
> error, please do not print, copy, retransmit, disseminate, or otherwise 
> use the information. Please notify the sender that
> 
> you have received this email in error, and delete the copy you received
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* [email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Pavel V. Smirnov
> *Sent:* Thursday, June 26, 2008 1:04 PM
> *To:* 'Yasir Khan'; [email-masked]
> *Subject:* RE: Using Signature Policy in RFC-5126
> 
>  
> 
> Yes, I mean “digital signature policy” as a “policy document” present at 
> SPUri. But I use SPUri only for example, you may specify a SigPolicyId 
> and omit sigPolicyQualifiers at all. In this case you have to rely on 
> some other means to convey a correspondence between SigPolicyIds and 
> “policy documents”.
> 
>  
> 
> In case of SPuri you have to retrieve a “policy document” by its URI and 
> hash it.
> 
>  
> 
> Note that if your infrastructure provides a trusted source of “policy 
> documents”, and there will never be two different (versions of) “policy 
> documents” identified by the same OID, you don’t have to hash them at 
> all. Just use zero policy hash value.
> 
>  
> 
> Pavel Smirnov
> 
> Crypto-Pro
> Tel./Fax: +7 495 780-4820
> WWW: http://www.CryptoPro.ru <http://www.cryptopro.ru/>
> e-mail: [email-masked] <mailto:[email-masked]>
> 
>  
> 
> *From:* [email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Yasir Khan
> *Sent:* Thursday, June 26, 2008 12:19 PM
> *To:* Смирнов Павел Владимирович; [email-masked]
> *Subject:* RE: Using Signature Policy in RFC-5126
> 
>  
> 
> You wrote: ”You have to hash a *digital signature policy* represented as 
> a sequence of bytes in some format and place the computed value in 
> SigPolicyHash.”
> 
>  
> 
> To which item you are naming as “digital signature policy”. You mean 
> policy document present at SPUri? If Yes then it makes some sense. But 
> if only SPUserNotice is present or nothing is present as 
> *sigPolicyQualifiers* as it is an OPTIONAL element:
> 
>  
> 
>             sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF 
> SigPolicyQualifierInfo OPTIONAL
> 
>  
> 
> then on which item the hash would be computed?
> 
>  
> 
> Regards,
> 
> Yasir Khan
> 
>  
> 
>  
> 
> ------------------------------------------------------------------------
> 
> *From:* Pavel V. Smirnov [mailto:[email-masked]]
> *Sent:* Wednesday, June 25, 2008 4:07 PM
> *To:* 'Yasir Khan'; [email-masked]
> *Subject:* RE: Using Signature Policy in RFC-5126
> 
>  
> 
> Hello Yasir,
> 
>  
> 
> There is no need to protect by SigPolicyHash other fields of 
> SignaturePolicyId structure because it is placed in a signed attribute. 
> All signed attributes are protected by the signature itself.
> 
>  
> 
> In most cases the policy would be an external document not included in 
> your signed message, and you have to unambiguously indicate specific 
> policy with respect to which your document should be treated. E.g., you 
> may only have an URI pointing to the policy as a SigPolicyQualifier.
> 
>  
> 
> You have to hash a digital signature policy represented as a sequence of 
> bytes in some format and place the computed value in SigPolicyHash.
> 
>  
> 
> Pavel Smirnov
> 
> Crypto-Pro
> Tel./Fax: +7 495 780-4820
> WWW: http://www.CryptoPro.ru <http://www.cryptopro.ru/>
> e-mail: [email-masked] <mailto:[email-masked]>
> 
>  
> 
> *From:* [email-masked] 
> [mailto:[email-masked]] *On Behalf Of *Yasir Khan
> *Sent:* Wednesday, June 25, 2008 2:43 PM
> *To:* [email-masked]
> *Subject:* Using Signature Policy in RFC-5126
> 
>  
> 
> We have a question related to using the signature policy in the CAdES 
> signatures (EPES) defined in RFC-5126. Here is the relevant structure:
> 
>  
> 
> SignaturePolicyId ::= SEQUENCE {
> 
>             sigPolicyIdentifier SigPolicyId,
> 
>             *sigPolicyHash SigPolicyHash,*
> 
>             sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
> 
>             SigPolicyQualifierInfo OPTIONAL
> 
> }
> 
>  
> 
> SigPolicyId ::= OBJECT IDENTIFIER
> 
>  
> 
> *SigPolicyHash ::= OtherHashAlgAndValue*
> 
> * *
> 
> *OtherHashAlgAndValue ::= SEQUENCE {*
> 
> *            hashAlgorithm   AlgorithmIdentifier,*
> 
> *        hashValue       OtherHashValue *
> 
> *}*
> 
>  
> 
> SigPolicyQualifierInfo ::= SEQUENCE {
> 
>             sigPolicyQualifierId SigPolicyQualifierId,
> 
>             sigQualifier ANY DEFINED BY sigPolicyQualifierId
> 
> }
> 
>  
> 
> SigPolicyQualifierId ::= OBJECT IDENTIFIER
> 
> id-spq-ets-uri OBJECT IDENTIFIER ::= {
> 
>             iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 
> pkcs9(9) smime(16) id-spq(5) 1
> 
> }
> 
> SPuri ::= IA5String
> 
>  
> 
> id-spq-ets-unotice OBJECT IDENTIFIER ::= {
> 
>             iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 
> pkcs9(9) smime(16) id-spq(5) 2
> 
> }
> 
> SPUserNotice ::= SEQUENCE {
> 
>             noticeRef NoticeReference OPTIONAL,
> 
>             explicitText DisplayText OPTIONAL
> 
> }
> 
>  
> 
> NoticeReference ::= SEQUENCE {
> 
>             organization DisplayText,
> 
>             noticeNumbers SEQUENCE OF INTEGER
> 
> }
> 
>  
> 
> DisplayText ::= CHOICE {
> 
>             visibleString VisibleString (SIZE (1..200)),
> 
>             bmpString BMPString (SIZE (1..200)),
> 
>             utf8String UTF8String (SIZE (1..200))
> 
> }
> 
>  
> 
> In the given structure for CAdES-EPES signature, its is not clear that 
> whether are we computing the hash "SigPolicyHash" over the document at 
> "SPuri" and/or over the "SPUserNotice"
> 
>  
> 
> Are the following combinations valid?
> 
>  
> 
> 1) Only compute hash over document present at SPURI if only SPUri is set
> 
> 2) Only compute hash over SPUserNotice  if only SPUserNotice is set
> 
> 3) Compute hash over document at SPURI and SPUserNotice if both are set
> 
>  
> 
> Please clarify it. Thanks!
> 
>  
> 
> Regards,
> 
>  
> 
> Yasir Khan
> Development Manager
> 
>  
> 
> Ascertia Ltd
> 40 Occam Road
> Surrey Research Park
> Guildford
> Surrey, GU2 7YG
> United Kingdom
> 
>  
> 
> t.  +44 (0)1483 685500
> f.  +44 (0)1483 573704
> 
>  
> 
> www.ascertia.com <http://www.ascertia.com/>   
> 
>  
> 
> -----------------------------------------------------------------
>          Identity Proven, Trust Delivered
> -----------------------------------------------------------------
> 
>  
> 
>  
> 

From: "Yasir Khan" <[email-masked]>
To: "'Pavel V. Smirnov'" <[email-masked]>, <[email-masked]>
Subject: RE: Using Signature Policy in RFC-5126
Date: Thu, 3 Jul 2008 21:07:15 +0500
Organization: Ascertia Limited
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_039F_01C8DD50.C5132EB0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_03A0_01C8DD50.C5132EB0"

------=_NextPart_001_03A0_01C8DD50.C5132EB0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

RFC 5126 explains how to create archived time stamp i.e.

=20

=20

ArchiveTimeStampToken ::=3D TimeStampToken

=20

   The value of the messageImprint field within TimeStampToken shall be

   a hash of the concatenation of:

=20

      - the encapContentInfo element of the SignedData sequence;

=20

      - any external content being protected by the signature, if the

        eContent element of the encapContentInfo is omitted;

=20

      - the Certificates and crls elements of the SignedData sequence,

        when present, and;

=20

      - all data elements in the SignerInfo sequence including all

        signed and unsigned attributes.

 =20

=20

The ArchiveTimeStamp will be added as an unsigned attribute in the
SignerInfo sequence.

=20

According to the RFC, it is clear that message imprint will be the hash =
of
above concatenated values but it is not explained how to concatenate =
these
values? Please clarify this point. Some hint for implementing this would =
be
highly appreciated. Thanks!

=20

-------------------------------------------------------------------------=
---
------

YASIR KHAN
Development Manager

=20

Ascertia Limited
 <http://www.ascertia.com/> www.ascertia.com  =20

www.globaltrustfinder.com <http://www.globaltrustfinder.com/> =20

-------------------------------------------------------------------------=
---
------

Delivering Trust for e-business Documents & Workflows

-------------------------------------------------------------------------=
---
------

NOTICE: This message is intended for the recipient(s) only. This
communication may contain privileged or other

confidential information. If you are not the intended recipient, or =
believe
that you have received this communication in

error, please do not print, copy, retransmit, disseminate, or otherwise =
use
the information. Please notify the sender that

you have received this email in error, and delete the copy you received

=20

  _____ =20

From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of Pavel V. Smirnov
Sent: Thursday, June 26, 2008 1:04 PM
To: 'Yasir Khan'; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

=20

Yes, I mean "digital signature policy" as a "policy document" present at
SPUri. But I use SPUri only for example, you may specify a SigPolicyId =
and
omit sigPolicyQualifiers at all. In this case you have to rely on some =
other
means to convey a correspondence between SigPolicyIds and "policy
documents".

=20

In case of SPuri you have to retrieve a "policy document" by its URI and
hash it.

=20

Note that if your infrastructure provides a trusted source of "policy
documents", and there will never be two different (versions of) "policy
documents" identified by the same OID, you don't have to hash them at =
all.
Just use zero policy hash value.

=20

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

=20

From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of Yasir Khan
Sent: Thursday, June 26, 2008 12:19 PM
To: =F3=CD=C9=D2=CE=CF=D7 =F0=C1=D7=C5=CC =
=F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

=20

You wrote: "You have to hash a digital signature policy represented as a
sequence of bytes in some format and place the computed value in
SigPolicyHash."

=20

To which item you are naming as "digital signature policy". You mean =
policy
document present at SPUri? If Yes then it makes some sense. But if only
SPUserNotice is present or nothing is present as sigPolicyQualifiers as =
it
is an OPTIONAL element:

=20

            sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF
SigPolicyQualifierInfo OPTIONAL

=20

then on which item the hash would be computed?

=20

Regards,

Yasir Khan

=20

=20

  _____ =20

From: Pavel V. Smirnov [mailto:[email-masked]]=20
Sent: Wednesday, June 25, 2008 4:07 PM
To: 'Yasir Khan'; [email-masked]
Subject: RE: Using Signature Policy in RFC-5126

=20

Hello Yasir,

=20

There is no need to protect by SigPolicyHash other fields of
SignaturePolicyId structure because it is placed in a signed attribute. =
All
signed attributes are protected by the signature itself.

=20

In most cases the policy would be an external document not included in =
your
signed message, and you have to unambiguously indicate specific policy =
with
respect to which your document should be treated. E.g., you may only =
have an
URI pointing to the policy as a SigPolicyQualifier.

=20

You have to hash a digital signature policy represented as a sequence of
bytes in some format and place the computed value in SigPolicyHash.

=20

Pavel Smirnov

Crypto-Pro
Tel./Fax: +7 495 780-4820
WWW:  <http://www.cryptopro.ru/> http://www.CryptoPro.ru
e-mail:  <mailto:[email-masked]> [email-masked]

=20

From: [email-masked] =
[mailto:[email-masked]]
On Behalf Of Yasir Khan
Sent: Wednesday, June 25, 2008 2:43 PM
To: [email-masked]
Subject: Using Signature Policy in RFC-5126

=20

We have a question related to using the signature policy in the CAdES
signatures (EPES) defined in RFC-5126. Here is the relevant structure:

=20

SignaturePolicyId ::=3D SEQUENCE {

            sigPolicyIdentifier SigPolicyId,

            sigPolicyHash SigPolicyHash,

            sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF

            SigPolicyQualifierInfo OPTIONAL

}

=20

SigPolicyId ::=3D OBJECT IDENTIFIER

=20

SigPolicyHash ::=3D OtherHashAlgAndValue

=20

OtherHashAlgAndValue ::=3D SEQUENCE {

            hashAlgorithm   AlgorithmIdentifier,

        hashValue       OtherHashValue=20

}

=20

SigPolicyQualifierInfo ::=3D SEQUENCE {

            sigPolicyQualifierId SigPolicyQualifierId,

            sigQualifier ANY DEFINED BY sigPolicyQualifierId

}

=20

SigPolicyQualifierId ::=3D OBJECT IDENTIFIER

id-spq-ets-uri OBJECT IDENTIFIER ::=3D {=20

            iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) =
pkcs9(9)
smime(16) id-spq(5) 1=20

}

SPuri ::=3D IA5String

=20

id-spq-ets-unotice OBJECT IDENTIFIER ::=3D {=20

            iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) =
pkcs9(9)
smime(16) id-spq(5) 2=20

}

SPUserNotice ::=3D SEQUENCE {

            noticeRef NoticeReference OPTIONAL,

            explicitText DisplayText OPTIONAL

}

=20

NoticeReference ::=3D SEQUENCE {

            organization DisplayText,

            noticeNumbers SEQUENCE OF INTEGER

}

=20

DisplayText ::=3D CHOICE {

            visibleString VisibleString (SIZE (1..200)),

            bmpString BMPString (SIZE (1..200)),

            utf8String UTF8String (SIZE (1..200))

}

=20

In the given structure for CAdES-EPES signature, its is not clear that
whether are we computing the hash "SigPolicyHash" over the document at
"SPuri" and/or over the "SPUserNotice"

=20

Are the following combinations valid?

=20

1) Only compute hash over document present at SPURI if only SPUri is set =

2) Only compute hash over SPUserNotice  if only SPUserNotice is set

3) Compute hash over document at SPURI and SPUserNotice if both are set

=20

Please clarify it. Thanks!

=20

Regards,

=20

Yasir Khan
Development Manager

=20

Ascertia Ltd
40 Occam Road=20
Surrey Research Park
Guildford
Surrey, GU2 7YG
United Kingdom

=20

t.  +44 (0)1483 685500
f.  +44 (0)1483 573704=20

=20

www.ascertia.com <http://www.ascertia.com/>    =20

=20

-----------------------------------------------------------------
         Identity Proven, Trust Delivered
-----------------------------------------------------------------

=20

=20

------=_NextPart_001_03A0_01C8DD50.C5132EB0
Content-Type: text/html;
	charset="koi8-r"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40"
xmlns:ns1=3D"http://schemas.microsoft.com/office/2004/12/omml">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dkoi8-r">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"Street"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PostalCode"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"address"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"country-region" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"City" =
downloadurl=3D"http://www.5iamas-microsoft-com:office:smarttags"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"place" downloadurl=3D"http://www.5iantlavalamp.com/"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}

 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Calibri;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle19
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>RFC 5126 explains how to create =
archived
time stamp i.e.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>ArchiveTimeStampToken ::=3D =
TimeStampToken<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A=9A The value of the =
messageImprint field
within TimeStampToken shall be<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A=9A a hash of the concatenation =
of:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A=9A=9A=9A=9A - the =
encapContentInfo element of
the SignedData sequence;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A=9A=9A=9A=9A - any external =
content being
protected by the signature, if the<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A=9A=9A=9A=9A=9A=9A eContent =
element of the
encapContentInfo is omitted;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A=9A=9A=9A=9A - the Certificates =
and crls elements
of the SignedData sequence,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A=9A=9A=9A=9A=9A=9A when present, =
and;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A=9A=9A=9A=9A - all data elements =
in the
SignerInfo sequence including all<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A=9A=9A=9A=9A=9A=9A signed and =
unsigned attributes.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>=9A <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>The ArchiveTimeStamp will be added =
as an
unsigned attribute in the SignerInfo =
sequence.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>According to the RFC, it is clear =
that
message imprint will be the hash of above concatenated values but it is =
not explained
how to concatenate these values? Please clarify this point. Some hint =
for implementing
this would be highly appreciated. Thanks!<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>------------------------------------------------------=
----------------------------</span></font><o:p></o:p></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>YASIR =
KHAN</span></font></b></strong><b><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy;font-weight:bold'><br>
</span></font></b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Development Manager<strong><b><font color=3Dnavy =
face=3DArial><span
style=3D'font-family:Arial;color:navy'><o:p></o:p></span></font></b></str=
ong></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dnavy =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Ascertia =
Limited</span></font></b></strong><font
size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'><br>
</span></font><a href=3D"http://www.ascertia.com/"
title=3D"blocked::http://www.ascertia.com/"><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>www.ascertia.com</span></fon=
t></a><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>&nbsp;&nbsp;
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a =
href=3D"http://www.globaltrustfinder.com/">www.globaltrustfinder.com</a>
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>------------------------------------------------------=
----------------------------</span></font><o:p></o:p></p>

<p class=3DMsoNormal><em><i><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Delivering Trust for e-business Documents &amp; =
Workflows<o:p></o:p></span></font></i></em></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>------------------------------------------------------=
----------------------------</span></font><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D1 color=3Dgray face=3DVerdana><span =
style=3D'font-size:
7.5pt;font-family:Verdana;color:gray'>NOTICE: This message is intended =
for the
recipient(s) only. This communication may contain privileged or =
other<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dgray face=3DVerdana><span =
style=3D'font-size:
7.5pt;font-family:Verdana;color:gray'>confidential information. If you =
are not
the intended recipient, or believe that you have received this =
communication in<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dgray face=3DVerdana><span =
style=3D'font-size:
7.5pt;font-family:Verdana;color:gray'>error, please do not print, copy,
retransmit, disseminate, or otherwise use the information. Please notify =
the
sender that<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D1 color=3Dgray face=3DVerdana><span =
style=3D'font-size:
7.5pt;font-family:Verdana;color:gray'>you have received this email in =
error,
and delete the copy you received</span></font><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Pavel V. Smirnov<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 26, =
2008 1:04
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Yasir Khan';
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Using =
Signature
Policy in RFC-5126</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Yes, I mean =
&#8220;digital
signature policy&#8221; as a &#8220;policy document&#8221; present at =
SPUri.
But I use SPUri only for example, you may specify a SigPolicyId and omit
sigPolicyQualifiers at all. In this case you have to rely on some other =
means
to convey a correspondence between SigPolicyIds and &#8220;policy =
documents&#8221;.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>In case of =
SPuri you
have to retrieve a &#8220;policy document&#8221; by its URI and hash =
it.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Note that =
if your
infrastructure provides a trusted source of &#8220;policy =
documents&#8221;, and
there will never be two different (versions of) &#8220;policy =
documents&#8221;
identified by the same OID, you don&#8217;t have to hash them at all. =
Just use
zero policy hash value.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DCalibri><span =
style=3D'font-size:
10.0pt;font-family:Calibri;color:navy'>Pavel =
Smirnov<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DCalibri><span =
style=3D'font-size:
10.0pt;font-family:Calibri;color:navy'>Crypto-Pro<br>
Tel./Fax: +7 495 780-4820<br>
WWW: </span></font><font size=3D2 color=3Dnavy face=3DCalibri><span =
lang=3DRU
style=3D'font-size:10.0pt;font-family:Calibri;color:navy'><a
href=3D"http://www.cryptopro.ru/" =
title=3D"http://www.cryptopro.ru/"><span
lang=3DEN-US>http://www.CryptoPro.ru</span></a></span></font><font =
size=3D2
color=3Dnavy face=3DCalibri><span =
style=3D'font-size:10.0pt;font-family:Calibri;
color:navy'><br>
e-mail: </span></font><font size=3D2 color=3Dnavy face=3DCalibri><span =
lang=3DRU
style=3D'font-size:10.0pt;font-family:Calibri;color:navy'><a
href=3D"mailto:[email-masked]" title=3D"mailto:[email-masked]"><span
lang=3DEN-US>[email-masked]</span></a></span></font><font size=3D2 =
color=3D"#1f497d"
face=3DCalibri><span =
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p></o:p><=
/span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt =
0pt 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0pt 0pt 0pt'>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DRU =
style=3D'font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=3D2 face=3DTahoma><span lang=3DRU =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Yasir Khan<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Thursday, June 26, =
2008
12:19 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =F3=CD=C9=D2=CE=CF=D7 =
=F0=C1=D7=C5=CC =F7=CC=C1=C4=C9=CD=C9=D2=CF=D7=C9=DE;
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Using =
Signature
Policy in RFC-5126<o:p></o:p></span></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DRU
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>You wrote: =
&#8221;You
have to hash a <b><span style=3D'font-weight:bold'>digital signature =
policy</span></b>
represented as a sequence of bytes in some format and place the computed =
value
in SigPolicyHash.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DCalibri><span =
style=3D'font-size:
11.0pt;font-family:Calibri;color:navy'>To which item you are naming as =
&#8220;digital
signature policy&#8221;. You mean policy document present at SPUri? If =
Yes then
it makes some sense. But if only SPUserNotice is present or nothing is =
present
as </span></font><b><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy;font-weight:bold'>sigPolicyQualifiers=
</span></font></b><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> <font
color=3Dnavy><span style=3D'color:navy'>as it is an OPTIONAL =
element</span></font></span></font><font
size=3D2 color=3Dnavy face=3DCalibri><span =
style=3D'font-size:11.0pt;font-family:Calibri;
color:navy'>:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo =
OPTIONAL<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>then on which item the hash would =
be
computed?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,<o:p></o:p></span></font></p=

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Yasir =
Khan<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</span></font></div>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Pavel =
V. Smirnov
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 25, =
2008
4:07 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Yasir Khan';
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Using =
Signature
Policy in RFC-5126</span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>Hello =
Yasir,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>There is no =
need to
protect by SigPolicyHash other fields of SignaturePolicyId structure =
because it
is placed in a signed attribute. All signed attributes are protected by =
the
signature itself.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>In most =
cases the
policy would be an external document not included in your signed =
message, and
you have to unambiguously indicate specific policy with respect to which =
your
document should be treated. E.g., you may only have an URI pointing to =
the
policy as a SigPolicyQualifier.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'>You have to =
hash a
digital signature policy represented as a sequence of bytes in some =
format and
place the computed value in SigPolicyHash.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DCalibri><span =
style=3D'font-size:
10.0pt;font-family:Calibri;color:navy'>Pavel =
Smirnov<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DCalibri><span =
style=3D'font-size:
10.0pt;font-family:Calibri;color:navy'>Crypto-Pro<br>
Tel./Fax: +7 495 780-4820<br>
WWW: </span></font><font size=3D2 color=3Dnavy face=3DCalibri><span =
lang=3DRU
style=3D'font-size:10.0pt;font-family:Calibri;color:navy'><a
href=3D"http://www.cryptopro.ru/" =
title=3D"http://www.cryptopro.ru/"><span
lang=3DEN-US>http://www.CryptoPro.ru</span></a></span></font><font =
size=3D2
color=3Dnavy face=3DCalibri><span =
style=3D'font-size:10.0pt;font-family:Calibri;
color:navy'><br>
e-mail: </span></font><font size=3D2 color=3Dnavy face=3DCalibri><span =
lang=3DRU
style=3D'font-size:10.0pt;font-family:Calibri;color:navy'><a
href=3D"mailto:[email-masked]" title=3D"mailto:[email-masked]"><span
lang=3DEN-US>[email-masked]</span></a></span></font><font size=3D2 =
color=3D"#1f497d"
face=3DCalibri><span =
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p></o:p><=
/span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:Calibri;color:#1F497D'><o:p>&nbsp;<=
/o:p></span></font></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0pt 0pt =
0pt 4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0pt 0pt 0pt'>

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span lang=3DRU =
style=3D'font-size:
10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=3D2 face=3DTahoma><span lang=3DRU =
style=3D'font-size:10.0pt;font-family:Tahoma'>
[email-masked] [mailto:[email-masked]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Yasir Khan<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, June 25, =
2008
2:43 PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Using Signature =
Policy in
RFC-5126<o:p></o:p></span></font></p>

</div>

</div>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DRU
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>We have a question related to using the signature =
policy in
the CAdES signatures (EPES) defined in RFC-5126. Here is the relevant
structure:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>SignaturePolicyId ::=3D SEQUENCE =
{<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
sigPolicyIdentifier SigPolicyId,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
<b><span style=3D'font-weight:bold'>sigPolicyHash =
SigPolicyHash,<o:p></o:p></span></b></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
sigPolicyQualifiers SEQUENCE SIZE (1..MAX) =
OF<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
SigPolicyQualifierInfo OPTIONAL<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>}<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>SigPolicyId ::=3D OBJECT =
IDENTIFIER<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>SigPolicyHash ::=3D =
OtherHashAlgAndValue<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'><o:p>&nbsp;</o:p></span></font></b></=
p>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>OtherHashAlgAndValue ::=3D SEQUENCE =
{<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; hashAlgorithm&nbsp;&nbsp;
AlgorithmIdentifier,<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;
hashValue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OtherHashValue =
<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><b><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;font-weight:bold'>}<o:p></o:p></span></font></b></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>SigPolicyQualifierInfo ::=3D SEQUENCE =
{<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
sigPolicyQualifierId SigPolicyQualifierId,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
sigQualifier ANY DEFINED BY =
sigPolicyQualifierId<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>}<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>SigPolicyQualifierId ::=3D OBJECT =
IDENTIFIER<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>id-spq-ets-uri OBJECT IDENTIFIER ::=3D { =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16)
id-spq(5) 1 <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>}<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>SPuri ::=3D IA5String<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>id-spq-ets-unotice OBJECT IDENTIFIER ::=3D { =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16)
id-spq(5) 2 <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>}<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>SPUserNotice ::=3D SEQUENCE =
{<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
noticeRef NoticeReference OPTIONAL,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
explicitText DisplayText OPTIONAL<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>}<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>NoticeReference ::=3D SEQUENCE =
{<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
organization DisplayText,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
noticeNumbers SEQUENCE OF INTEGER<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>}<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>DisplayText ::=3D CHOICE =
{<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
visibleString VisibleString (SIZE =
(1..200)),<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
bmpString BMPString (SIZE (1..200)),<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;
utf8String UTF8String (SIZE (1..200))<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>}<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>In the given structure for CAdES-EPES signature, its =
is not
clear that whether are we computing the hash &quot;SigPolicyHash&quot; =
over the
document at &quot;SPuri&quot; and/or over the =
&quot;SPUserNotice&quot;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Are the following combinations =
valid?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>1) Only compute hash over document present at SPURI =
if only
SPUri is set <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>2) Only compute hash over SPUserNotice&nbsp; if only
SPUserNotice is set<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>3) Compute hash over document at SPURI and =
SPUserNotice if
both are set<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Please clarify it. =
Thanks!<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Yasir Khan<br>
Development Manager<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Ascertia Ltd<br>
<st1:Street w:st=3D"on"><st1:address w:st=3D"on">40 Occam =
Road</st1:address></st1:Street>
<br>
<st1:place w:st=3D"on">Surrey</st1:place> Research Park<br>
<st1:place w:st=3D"on">Guildford</st1:place><br>
<st1:place w:st=3D"on"><st1:City w:st=3D"on">Surrey</st1:City>, =
<st1:PostalCode
 w:st=3D"on">GU2 7YG</st1:PostalCode></st1:place><br>
<st1:country-region w:st=3D"on"><st1:place w:st=3D"on">United =
Kingdom</st1:place></st1:country-region><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>t.&nbsp; +44 (0)1483 685500<br>
f.&nbsp; +44 (0)1483 573704 <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><a href=3D"http://www.ascertia.com/"
title=3D"blocked::http://www.ascertia.com/">www.ascertia.com</a>&nbsp;&nb=
sp;&nbsp;
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>&nbsp;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>------------------------------------------------------=
-----------<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Identity Proven, Trust
Delivered<br>
-----------------------------------------------------------------<o:p></o=
:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</div>

</div>

</body>

</html>

------=_NextPart_001_03A0_01C8DD50.C5132EB0--

------=_NextPart_000_039F_01C8DD50.C5132EB0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_039F_01C8DD50.C5132EB0--

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: FW: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt 
Date: Wed, 2 Jul 2008 16:38:05 -0400
Organization: IECA, Inc.
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C8DC62.01556AE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I'd like to draw attention to this ID.  Alba and Francesco described the PEC
(Posta Elettronica Certificata) at IETF 71
(https://www3.ietf.org/proceedings/08mar/slides/smime-4.pdf) and this is the
ID that provides a much more detailed technical description of PEC.  Many at
the meeting indicated they were willing to review - so please do and provide
comments to the authors.

spt 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, June 30, 2008 6:30 PM
To: [email-masked]
Subject: I-D ACTION:draft-gennai-smime-cnipa-pec-00.txt 

	Title		: Certified Electronic Mail
	Author(s)	: F. Gennai, A. Shahin, C. Petrucci, A. Vinciarelli
	Filename	: draft-gennai-smime-cnipa-pec-00.txt
	Pages		: 62
	Date		: 2008-6-30
	
Since 1997, the Italian Laws have recognized electronic delivery 
   systems as legally usable. After 2 years of technical tests, in 
   2005 the characteristics of an official electronic delivery 
   service, named certified electronic mail (in Italian "Posta 
   Elettronica Certificata") were defined, giving the system legal 
   value.  

   Design of the entire system was carried out by the National 
   Center for Informatics in the Public Administration of Italy 
   (CNIPA), followed by efforts for the implementation and testing 
   of the service. The CNIPA has given the Italian National 
   Research Council (CNR), and in particular The Institute of 
   Information Science and Technologies at the CNR (ISTI), the task 
   to run tests on providers of the service to guarantee the 
   correct implementation and interoperability.This document 
   describes the certified email system adopted in Italy. It 
   represents the system as it is at the moment of writing, 
   following the technical regulations that were written based upon 
   the Italian Law DPR. November 2, 2005. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-gennai-smime-cnipa-pec-00.txt

------=_NextPart_000_0000_01C8DC62.01556AE0
Content-Type: Message/External-body;
	name="draft-gennai-smime-cnipa-pec-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="draft-gennai-smime-cnipa-pec-00.txt"

Content-Type: text/plain
Content-ID: <[email-masked]>

------=_NextPart_000_0000_01C8DC62.01556AE0
Content-Type: text/plain;
	name="ATT00115.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00115.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

------=_NextPart_000_0000_01C8DC62.01556AE0--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3278bis-01.txt 
Date: Tue,  1 Jul 2008 10:15:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

	Title		: Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)
	Author(s)	: S. Turner, D. Brown
	Filename	: draft-ietf-smime-3278bis-01.txt
	Pages		: 50
	Date		: 2008-7-1
	
This document describes how to use Elliptic Curve Cryptography (ECC) 
   public-key algorithms in the Cryptographic Message Syntax (CMS).  The 
   ECC algorithms support the creation of digital signatures and the 
   exchange of keys to encrypt or authenticate content.  The definition 
   of the algorithm processing is based on the ANSI X9.62 standard, 
   developed by the ANSI X9F1 working group, the IEEE 1363 standard, and 
   the SEC 1 standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-3278bis-01.txt

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-3278bis-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-3851bis-04.txt 
Date: Tue,  1 Jul 2008 10:15:01 -0700 (PDT)
Sender: [email-masked]

--NextPart

	

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-smime-3851bis-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--NextPart--