headers
Russ Housley | 2 Jan 2007 19:33

Re: I-D ACTION:draft-ietf-smime-multisig-00.txt

Denis:

I do not know how to constructively continue this discussion.  We do not seem to be communicating with each other.

Trying one more time...  See below.

[Russ]
Denis:

We are talking about signatures on CMS object, not signatures on
certificates. The recipient of the signed CMS object needs to be
able to validate the signature on the certificate as well as the CMS
signed object.

If the signer has a certified RSA public key, then the signer can
sign a CMS object using both RSA with SHA-1 and RSA with
SHA-256. Each one will be a SignerInfo, and the sid (using either
the issuerAndSerialNumber or the subjectKeyIdentifier) in each of
them will identify the same certified public key.

[Denis]
 
If the algorithm is "RSA" rather than "a hash function + RSA", then it works.
However, this kind of explanation is lacking in the current draft.

In most certificates used for S/MIME today, the subject public key identifier contains the algorithm identifier listed in 2.3.1 of RFC 3279:

   The OID rsaEncryption identifies RSA public keys.

      pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                     rsadsi(113549) pkcs(1) 1 }

      rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}

Then, the CMS SignerInfo indicates RSA as well as the one-way hash function that is used for the encapsulated content.  These are the OID that I found in the RFCs:

      md2WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 2 }

      md5WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 4 }

      sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 5 }

      sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }

      sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 11 }

      sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 12 }

      sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 13 }

The certificate does not require the subject public key to be used with any particular one-way hash function, but the signature itself tells which one-way hash function way employed by the signer.  None of this is new!

What text needs to be added to the document?  I am willing to consider additional text, but so far, I do not see a need.

 [Russ]

If the RSA public key is placed in two certificates, one signed by
the CA using RSA with SHA-1 and the other signed by the CA using RSA
with SHA-256, then you get a better situation from a cryptographic
strength perspective. However, the subject key identifier will be
the same in both certificates, which allows the recipient to easily
detect that the signatures are from the same signer if that form of
sid is used. Which is the one that S/MIME has been encouraging for
quite some years, mostly due to size.
[Denis]
 
I disagree. RFC 3280 states:
 
4.2.1.2  Subject Key Identifier

   The subject key identifier extension provides a means of identifying
   certificates that contain a particular public key.

   (...)

   For end entity certificates, subject key identifiers SHOULD be
   derived from the public key.

You did not quote the part of Section 4.2.1.2 of RFC 3280 that describe the most commonly used technique for computing a key identifier:

      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
      value of the BIT STRING subjectPublicKey (excluding the tag,
      length, and number of unused bits).

If the two certificates contain the same RSA public key, then this value will most certainly be the same!

 Since the public keys will be different, the subject key identifiers will NOT be the same in both certificates.

Again, if the two certificates contain the same RSA public key, then this value will most certainly be the same!  You seem to be making some unstated assumptions about certification policies.

If the certificates are issued by the same CA, the subject field from the certificate would normally be the same.
If the certificates are not issued by the same CA, the permanent identifier, if present would help.
These kinds of explanations are lacking in the current draft.

I am not trying to distinguish the certificates.  The issuer and serial number would allow me to do that.

At this point, I do not know what else to say.  I am going to leave it to the S/MIME WG Chairs to determine what changes, if any, are needed to resolve your Last Call comment.

Russ
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 2 Jan 2007 21:50
Picon
Favicon

I-D ACTION:draft-ietf-smime-cms-auth-enveloped-00.txt

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		: The CMS AuthEnvelopedData Content Type
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-auth-enveloped-00.txt
	Pages		: 9
	Date		: 2007-1-2
	
   This document describes an additional content type for the
   Cryptographic Message Syntax (CMS).  The AuthEnvelopedData content
   type is intended for use with authenticated encryption modes.  All of
   the various key management techniques that are supported in the
   EnvelopedData content type are also supported by the
   AuthEnvelopedData content type.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-auth-enveloped-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-smime-cms-auth-enveloped-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-auth-enveloped-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment: message/external-body, 147 bytes
Attachment (draft-ietf-smime-cms-auth-enveloped-00.txt): message/external-body, 68 bytes
_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce
Permalink | Reply | 0 comments |
headers
Turner, Sean P. | 3 Jan 2007 15:43

WG LC closed on esscertid


All,

The WG LC has closed on the esscertid.  An updated draft has been published
to address comments raised and I will now forward it to the Security AD.

spt
Permalink | Reply | 0 comments |
headers
Turner, Sean P. | 3 Jan 2007 15:40

RE: I-D ACTION:draft-ietf-smime-multisig-00.txt


Dennis,

Comments inline..

-----Original Message-----
From: owner-ietf-smime <at> mail.imc.org [mailto:owner-ietf-smime <at> mail.imc.org]
On Behalf Of Denis Pinkas
Sent: Tuesday, December 26, 2006 6:19 AM
To: ietf-smime <at> imc.org
Subject: Re: I-D ACTION:draft-ietf-smime-multisig-00.txt

Comments on draft-ietf-smime-multisig-00.txt

..snip

However, this draft is unclear on how it applies. There are three types of
RPs concerned with this draft:

a)	RPs able to process "weak" algorithms, 
b)	RPs able to process "strong" algorithms only, and
c)	RPs able to process both "weak" and "strong" algorithms.

spt> The draft is intended to address all three types of RPs.

In case a, the main advantage of this draft is to allow to link digital
signatures from the same signer in case of algorithm migration. If the RP
decodes a SignerInfo with the "strong" algo, then it cannot verify the
digital signature, but then it can easily figure out that there is another
signature with the weak algorithms that it can process. The draft is silent
about this scenario.

spt> The main advantage of the draft is to allow you to know if an attacker
stripped off a SignerInfo.  I will add the point about being easier able to
find the other signature if you only support one of the two.

In case b, the RPs is only able to process strong algorithms. If the RP
decodes a SignerInfo with the "weak" algo, then it can also figure out that
there is another signature that it can process. 
The draft is silent about this scenario.

spt> See above.

In case c, the RPs is able to process both the weak and the strong
algorithms. If the RP decodes a SignerInfo with the "weak" algo, then it can
also figure out that there is another signature that it can process. What
about if a single bit from the digital signature made with the stronger
algorithm is changed by an attacker ? The digital signature is not
suppressed, but becomes invalid. 
What should the RP do ? The draft is silent about this scenario. 

spt> We will add text to address this - this part was going to go in to
section 5.

The draft does not say either whether it applies to the verification of a
CMS structure at the present time or at a time in the past. 

If it is the present time, both the "weak" and "strong" algorithms are safe,
and there is no concern for the "downgrade attack".

If it is a time in the past, then it is important to make a difference
between :

-	the weakness of hash algorithms, and 
-	the weakness of asymmetric algorithm of short keys. 

In the later case, time-stamping or time-marking over the digital signature
provides a protection. 

In the former case, time-stamping or time-marking over the digital signature
does not provide a protection, but an archive time-stamping provides a
protection, since a different and stronger hash algorithm may be used.

This means that there exist solutions to handle the problem without the need
to use the new signed attribute.

spt> I do not believe time should have anything to do with this. If you're
not worried about downgrade attacks then don't use the attribute.

In addition, RPs should know which hash algorithms is no more safe, which
means that they will not use the digital signature made with a weak
algorithm. They may try to use the newly defined MultipleSignatures signed
attribute to find out another signature made with a strong algorithm. In
other words, the "downgrade attack" 
is not a concern, but the newly defined MultipleSignatures signed attribute
is useful to link signatures from the same signer. The abstract should be
changed. Hereafter is a proposal: 

spt> While this might be true there are times when an RP won't know and this
draft addresses those instances.

      CMS SignedData includes the SignerInfo structure to convey per-
      signer information. SignedData supports multiple signers and 
      multiple signature algorithms per-signer with multiple SignerInfo 
      structures. During periods of algorithm migration, a signer may 
      wish to attach more than one SignerInfo. However, there is no 
      way to identify that they are from the same signer. This document 
      defines a signed attribute, its generation rules, and its 
      processing rules to allow a RP to detect SignerInfo structures 
      generated by the same signer.

spt> The point of the draft is to protect against a downgrade attack and I
will not change the abstract because I believe your suggestion misses the
point of the draft.

The processing rules for the various RPs should be given (six cases should
be covered).

spt> Agreed that we need to fill in the processing rules.

The MultipleSignature attribute, as defined, is not good enough, to
establish a link without ambiguity.

           MultipleSignature ::= SEQUENCE { 
             bodyHashAlg     DigestAlgorithIdentifier, 
             signAlg         SignatureAlgorithmIdentifier, 
             signAttrsHash   SignAttrsHash, 
             cert            ESSCertIDv2 OPTIONAL} 

If the same algorithm are used (e.g. SHA-1 with RSA) bodyHashAlg and signAlg
will likely be the same. 
If a signature has few signed attributes signAttrsHash will also likely be
the same. The difference will always be guaranteed with cert, which thus
should be made mandatory. 

spt> No the digest alg is sha-1 and the signature alg is rsa with sha-1 so
the values are different. 

Denis

>It is a companion document, not a replacement.
>
>Russ
>
>At 05:28 AM 12/20/2006, Denis Pinkas wrote:
>
>>How does this document relate to <draft-ietf-smime-cms-mult-sign-02.txt> ?
>>
>>Does it replace it ?
>>
>>Denis
>>
>> >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           : Multiple Signatures in S/MIME
>> >       Author(s)       : S. Turner
>> >       Filename        : draft-ietf-smime-multisig-00.txt
>> >       Pages           :
>> >       Date            : 2006-12-19
>> >
>> >         CMS SignedData includes the SignerInfo structure to convey per-
>> >         signer information. SignedData supports multiple signers and
>> >         multiple signature algorithms per-signer with multiple
SignerInfo
>> >         structures. If a signer attaches more than one
>> SignerInfo, there are
>> >         concerns that an attacker could perform a downgrade attack by
>> >         removing the SignerInfo(s) with the 'stronger' algorithm(s).
This
>> >         document defines a signed attribute, its generation rules, and
its
>> >         processing rules to allow signers to convey multiple SignerInfo
>> >         while protecting against downgrade attacks. Additionally, this
>> >         attribute may assist during periods of algorithm migration.
>> >
>> >
>> >A URL for this Internet-Draft is:
>> >http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-00.txt
>> >
>> >To remove yourself from the I-D Announcement list, send a message to 
>> >i-d-announce-request <at> ietf.org with the word unsubscribe in the body 
>> >of the message.
>> >You can also visit 
>> >https://www1.ietf.org/mailman/listinfo/I-D-announce
>> >to change your subscription settings.
>> >
>> >Internet-Drafts are also available by anonymous FTP. Login with the 
>> >username "anonymous" and a password of your e-mail address. After 
>> >logging in, type "cd internet-drafts" and then "get 
>> >draft-ietf-smime-multisig-00.txt".
>> >
>> >A list of Internet-Drafts directories can be found in 
>> >http://www.ietf.org/shadow.html or 
>> >ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> >
>> >Internet-Drafts can also be obtained by e-mail.
>> >
>> >Send a message to:
>> >       mailserv <at> ietf.org.
>> >In the body type:
>> >       "FILE /internet-drafts/draft-ietf-smime-multisig-00.txt".
>> >
>> >NOTE:  The mail server at ietf.org can return the document in
>> >       MIME-encoded form by using the "mpack" utility.  To use this
>> >       feature, insert the command "ENCODING mime" before the "FILE"
>> >       command.  To decode the response(s), you will need "munpack" or
>> >       a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>> >       exhibit different behavior, especially when dealing with
>> >       "multipart" MIME messages (i.e. documents which have been split
>> >       up into multiple messages), so check your local documentation on
>> >       how to manipulate these messages.
>> >
>> >Below is the data which will enable a MIME compliant mail reader 
>> >implementation to automatically retrieve the ASCII version of the 
>> >Internet-Draft.
>> >
>> >Content-Type: text/plain
>> >Content-ID:    <2006-12-19135046.I-D <at> ietf.org>
>> >
>> >ENCODING mime
>> >FILE /internet-drafts/draft-ietf-smime-multisig-00.txt
Permalink | Reply | 0 comments |
headers
Turner, Sean P. | 4 Jan 2007 18:27

WG LC closed on draft-ietf-smime-cms-mult-sign


All,

The WG LC has closed on the draft-ietf-smime-cms-mult-sign.  I will now
forward it to the Security AD and as noted earlier I will make sure to note
Denis' concerns.

spt
Permalink | Reply | 0 comments |
headers
Denis Pinkas | 9 Jan 2007 14:01
Picon

Re: I-D ACTION:draft-ietf-smime-multisig-00.txt


Sean,

My replies are in line too.

>Dennis,
>
>Comments inline..
>
>-----Original Message-----
>From: owner-ietf-smime <at> mail.imc.org [mailto:owner-ietf-smime <at> mail.imc.org]
>On Behalf Of Denis Pinkas
>Sent: Tuesday, December 26, 2006 6:19 AM
>To: ietf-smime <at> imc.org
>Subject: Re: I-D ACTION:draft-ietf-smime-multisig-00.txt
>
>
>Comments on draft-ietf-smime-multisig-00.txt
>
>..snip
>
>However, this draft is unclear on how it applies. There are three types of
>RPs concerned with this draft:
>
>a)	RPs able to process "weak" algorithms, 
>b)	RPs able to process "strong" algorithms only, and
>c)	RPs able to process both "weak" and "strong" algorithms.
>
>spt> The draft is intended to address all three types of RPs.

This is what I believed, but these cases are not discussed in detail in the text.
I am  awaiting some new text.

>In case a, the main advantage of this draft is to allow to link digital
>signatures from the same signer in case of algorithm migration. If the RP
>decodes a SignerInfo with the "strong" algo, then it cannot verify the
>digital signature, but then it can easily figure out that there is another
>signature with the weak algorithms that it can process. The draft is silent
>about this scenario.
>
>spt> The main advantage of the draft is to allow you to know if an attacker
>stripped off a SignerInfo.  I will add the point about being easier able to
>find the other signature if you only support one of the two.
>
>In case b, the RPs is only able to process strong algorithms. If the RP
>decodes a SignerInfo with the "weak" algo, then it can also figure out that
>there is another signature that it can process. 
>The draft is silent about this scenario.
>
>spt> See above.
>
>In case c, the RPs is able to process both the weak and the strong
>algorithms. If the RP decodes a SignerInfo with the "weak" algo, then it can
>also figure out that there is another signature that it can process. What
>about if a single bit from the digital signature made with the stronger
>algorithm is changed by an attacker ? The digital signature is not
>suppressed, but becomes invalid. 
>What should the RP do ? The draft is silent about this scenario. 
>
>spt> We will add text to address this - this part was going to go in to
>section 5.

OK. I am  awaiting some new text.

>The draft does not say either whether it applies to the verification of a
>CMS structure at the present time or at a time in the past. 
>
>If it is the present time, both the "weak" and "strong" algorithms are safe,
>and there is no concern for the "downgrade attack".
>
>If it is a time in the past, then it is important to make a difference
>between :
>
>-	the weakness of hash algorithms, and 
>-	the weakness of asymmetric algorithm of short keys. 
>
>In the later case, time-stamping or time-marking over the digital signature
>provides a protection. 
>
>In the former case, time-stamping or time-marking over the digital signature
>does not provide a protection, but an archive time-stamping provides a
>protection, since a different and stronger hash algorithm may be used.
>
>This means that there exist solutions to handle the problem without the need
>to use the new signed attribute.

>spt> I do not believe time should have anything to do with this. If you're
>not worried about downgrade attacks then don't use the attribute.

The key point is to explain when this attribute is really useful. 
When you will have detailed the six cases, which case, if any, makes that attribute useful ?
The anwser could be none.

>In addition, RPs should know which hash algorithms is no more safe, which
>means that they will not use the digital signature made with a weak
>algorithm. They may try to use the newly defined MultipleSignatures signed
>attribute to find out another signature made with a strong algorithm. In
>other words, the "downgrade attack" 
>is not a concern, but the newly defined MultipleSignatures signed attribute
>is useful to link signatures from the same signer. The abstract should be
>changed. Hereafter is a proposal: 

>spt> While this might be true there are times when an RP won't know and this
>draft addresses those instances.

Really ? I believe that the local security policy of the recipient needs to know whether SHA-1 is secure
enough 
and whether SHA-1 is better or lower than SHA-256.

>      CMS SignedData includes the SignerInfo structure to convey per-
>      signer information. SignedData supports multiple signers and 
>      multiple signature algorithms per-signer with multiple SignerInfo 
>      structures. During periods of algorithm migration, a signer may 
>      wish to attach more than one SignerInfo. However, there is no 
>      way to identify that they are from the same signer. This document 
>      defines a signed attribute, its generation rules, and its 
>      processing rules to allow a RP to detect SignerInfo structures 
>      generated by the same signer.
>
>spt> The point of the draft is to protect against a downgrade attack and I
>will not change the abstract because I believe your suggestion misses the
>point of the draft.

This point still needs to be proven.

>The processing rules for the various RPs should be given (six cases should
>be covered).

>spt> Agreed that we need to fill in the processing rules.

OK. I am  awaiting some new text.

>The MultipleSignature attribute, as defined, is not good enough, to
>establish a link without ambiguity.
>
>           MultipleSignature ::= SEQUENCE { 
>             bodyHashAlg     DigestAlgorithIdentifier, 
>             signAlg         SignatureAlgorithmIdentifier, 
>             signAttrsHash   SignAttrsHash, 
>             cert            ESSCertIDv2 OPTIONAL} 
>
>If the same algorithm are used (e.g. SHA-1 with RSA) bodyHashAlg and signAlg
>will likely be the same. 
>If a signature has few signed attributes signAttrsHash will also likely be
>the same. The difference will always be guaranteed with cert, which thus
>should be made mandatory. 

>spt> No the digest alg is sha-1 and the signature alg is rsa with sha-1 so
>the values are different. 

OK. You are correct.

Denis

>Denis
Permalink | Reply | 0 comments |
headers
Denis Pinkas | 9 Jan 2007 13:52
Picon

Re: I-D ACTION:draft-ietf-smime-multisig-00.txt

Russ,
 
The main message that I extracted from your e-mail is the following :
 
"What text needs to be added to the document ? 
  I am willing to consider additional text, but so far, I do not see a need".
 
I spent several hours working on a suitable text. You will find herafter my proposed
replacements for the two text replacements.
 
First replacement:
 

   A recipient verifies a signature in the following way :

 

   It must first identify the signer's public key to be used for the

   verification.  The signer's public key is referenced in the sid

   value either by an issuer distinguished name along with an

   issuer-specific serial number or by a subject key identifier that

   identifies the certificate containing the public key.  If the
   essCertID signed attribute is present, then the public key

   contained in the referenced certificate shall be used.  The
   signer's certificate may be included in the SignedData certificates
   field.

 

   It must verify that the signatureAlgorithm indicated in the

   SignerInfo value is compatible with the digestAlgorithm indicated

   in the SignerInfo value and the algorithm contained in the

   subjectPublicKeyInfo from the signer’s certificate, e.g. if the

   signatureAlgorithm is sha-1WithRSAEncryption then the

   digestAlgorithm must be id-sha1 and the algorithm contained in the

   subjectPublicKeyInfo must be rsaEncryption. In addition, it must

   verify that the strength and key size of these algorithms are

   conformant with its local security policy, otherwise it shall

   discard the signature.

 

   It must then use the specific digestAlgorithm indicated in the

   SignerInfo value to compute a digest and the signatureAlgorithm

   indicated in the SignerInfo value with to verify the signature

   value, as defined in Section 5.3.

 

   A given signer may apply more than one signature.  This may be

   useful in particular when some recipients are unable to process

   some algorithms during an algorithm migration phase.

 

Second replacement:
 

   signerInfos is a collection of per-signer information.  There MAY

   be any number of elements in the collection, including zero.  In

   order to determine whether some signatures were generated by the

   same signer, the simple matching of the signer identifier may first

   be used.  However, it is only appropriate when the same signature

   algorithm and key size is being used with a different digest

   function.  An additional means, is to check whether the subject

   field and the issuer field from two signer’s certificates are the

   same and relate to the same superior CA.  The latter situation may

   happen, for example, when the signed-data content type includes

   signatures generated with the RSA signature algorithm and with the

   ECDSA signature algorithm and when the certificates are issued by

   the same CA.  When the signer’s certificates are not issued by the

   same CA and if they contain a permanent identifier field, then it

   is possible to check whether two certificates relate to the same

   signer.

 

   The successful validation of one signature from the same signer

   which conforms to the local security policy, ought to be treated as

   a successful validation of the signed-data content type for that

   signer.

 

   The details of the SignerInfo type are discussed in section 5.3. 

   Since each signer can employ a different digital signature

   technique and future specifications could update the syntax, all

   implementations MUST gracefully handle unimplemented versions of

   SignerInfo.  Further, since all implementations will not support

   every possible signature algorithm, all implementations MUST

   gracefully handle unimplemented signature algorithms when they are

   encountered.

 

A few explanations.
 
1 - The current explanations from CMS (in fact from PKCS#7) are far insufficient to provide
sufficient guidance for a correct verification. This needed to be fixed and has been fixed in
the first text proposal.
 
2 - In the second text replacement, I have detailed the verification process so that a recipent may know
that two signerInfo relate to the same signer.
 
3 - The key sentence from the draft I cannot agree with is the following:
 

  When the collection represents more than one signature, the successful

  validation of one of signature from each signer ought to be treated

  as a successful validation of the signed-data content type. 

 
This sentence speaks about a global validation of a signed document that would be valid,
if every signer placed one correct signature. However, with CMS signatures are verified one by one.
There is no notion of the validation of a document by multiple signers.
 
This sentence has been replaced with :
 

   The successful validation of one signature from the same signer

   which conforms to the local security policy, ought to be treated as

   a successful validation of the signed-data content type for that

   signer.

 
Denis
 
Denis:

I do not know how to constructively continue this discussion.  We do not seem to be communicating with each other.

Trying one more time...  See below.

[Russ]
Denis:

We are talking about signatures on CMS object, not signatures on
certificates. The recipient of the signed CMS object needs to be
able to validate the signature on the certificate as well as the CMS
signed object.

If the signer has a certified RSA public key, then the signer can
sign a CMS object using both RSA with SHA-1 and RSA with
SHA-256. Each one will be a SignerInfo, and the sid (using either
the issuerAndSerialNumber or the subjectKeyIdentifier) in each of
them will identify the same certified public key.

[Denis]

  If the algorithm is "RSA" rather than "a hash function + RSA", then it works.
However, this kind of explanation is lacking in the current draft.

In most certificates used for S/MIME today, the subject public key identifier contains the algorithm identifier listed in 2.3.1 of RFC 3279:

   The OID rsaEncryption identifies RSA public keys.

      pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                     rsadsi(113549) pkcs(1) 1 }

      rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}

Then, the CMS SignerInfo indicates RSA as well as the one-way hash function that is used for the encapsulated content.  These are the OID that I found in the RFCs:

      md2WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 2 }

      md5WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 4 }

      sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 5 }

      sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }

      sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 11 }

      sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 12 }

      sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 13 }

The certificate does not require the subject public key to be used with any particular one-way hash function, but the signature itself tells which one-way hash function way employed by the signer.  None of this is new!

What text needs to be added to the document?  I am willing to consider additional text, but so far, I do not see a need.

 [Russ]

If the RSA public key is placed in two certificates, one signed by
the CA using RSA with SHA-1 and the other signed by the CA using RSA
with SHA-256, then you get a better situation from a cryptographic
strength perspective. However, the subject key identifier will be
the same in both certificates, which allows the recipient to easily
detect that the signatures are from the same signer if that form of
sid is used. Which is the one that S/MIME has been encouraging for
quite some years, mostly due to size.
[Denis]

  I disagree. RFC 3280 states:

  4.2.1.2  Subject Key Identifier

   The subject key identifier extension provides a means of identifying
   certificates that contain a particular public key.

   (...)

   For end entity certificates, subject key identifiers SHOULD be
   derived from the public key.

You did not quote the part of Section 4.2.1.2 of RFC 3280 that describe the most commonly used technique for computing a key identifier:

      (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
      value of the BIT STRING subjectPublicKey (excluding the tag,
      length, and number of unused bits).

If the two certificates contain the same RSA public key, then this value will most certainly be the same!

 Since the public keys will be different, the subject key identifiers will NOT be the same in both certificates.

Again, if the two certificates contain the same RSA public key, then this value will most certainly be the same!  You seem to be making some unstated assumptions about certification policies.

If the certificates are issued by the same CA, the subject field from the certificate would normally be the same.
If the certificates are not issued by the same CA, the permanent identifier, if present would help.
These kinds of explanations are lacking in the current draft.

I am not trying to distinguish the certificates.  The issuer and serial number would allow me to do that.

At this point, I do not know what else to say.  I am going to leave it to the S/MIME WG Chairs to determine what changes, if any, are needed to resolve your Last Call comment.

Russ
Permalink | Reply | 0 comments |
headers
Tobias Gondrom | 9 Jan 2007 20:22
Picon
Favicon

Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt - until Jan 23rd


Hello dear SMIME WG,

at the last meeting of the LTANS WG in San Diego, Russ recommended to
ask your WG for a cross review of the ERS draft in its final stage (it
is currently in WGLC). 

http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-09.txt 

It would be nice if some of you could read the draft, review it and
provide your feedback. 

(As probably most of you already know the draft is about the data
structure for an Evidence Record to ensure and protect integrity of data
and signatures even when the algorithms used at signing time become
insecure at a later point in time.)

WG Last Call runs until January 23rd. 
If some of you need longer, please send me a note about how much time
you need. 

Thank you very much for your help, Tobias
Chair of LTANS

> -----Original Message-----
> From: Tobias Gondrom
> Sent: Tuesday, January 09, 2007 8:12 PM
> To: ietf-ltans <at> imc.org
> Cc: 'Carl Wallace'
> Subject: WG Last Call: draft-ietf-ltans-ers-09.txt - until Jan 23rd
> Importance: High
> 
> Hello dear LTANS WG,
> 
> with the small adjustments made in version-9, based on the discussion
at
> the meeting in San Diego, I again initiate the formal final WG last
call.
> (Hopefully this time it will really be the last one ;-) )
> 
> Additionally I will also ask the SMIME WG for cross review of the
draft as
> it has been discussed and decided at the last meeting in San Diego.
> 
> WG Last Call closes on January 23rd. After which the revised document
will
> hopefully be ready for submission to the IESG.
> 
> Thank you, Tobias
> 
> 
> Ps.: btw. the ltans-reqs document passed the IETF Last Call and is now
in
> its final preparation phase by the IETF editor team.
> 
> 
> 
> > -----Original Message-----
> > From: owner-ietf-ltans <at> mail.imc.org [mailto:owner-ietf-
> ltans <at> mail.imc.org]
> > On Behalf Of Internet-Drafts <at> ietf.org
> > Sent: Friday, January 05, 2007 12:50 AM
> > To: i-d-announce <at> ietf.org
> > Cc: ietf-ltans <at> imc.org
> > Subject: I-D ACTION:draft-ietf-ltans-ers-09.txt
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Long-Term Archive and Notary
Services
> > Working Group of the IETF.
> >
> > 	Title		: Evidence Record Syntax (ERS)
> > 	Author(s)	: R. Brandner, et al.
> > 	Filename	: draft-ietf-ltans-ers-09.txt
> > 	Pages		: 29
> > 	Date		: 2007-1-4
> >
> > In many scenarios, users must be able prove the existence and
> >    integrity of data, including digitally signed data, in a common
and
> >    reproducible way over a long and possibly undetermined period of
> >    time.  This document specifies the syntax and processing of an
> >    Evidence Record, a structure designed to support long-term non-
> >    repudiation of existence of data.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-09.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> > i-d-announce-request <at> ietf.org with the word unsubscribe in the body
of
> > the message.
> > You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username "anonymous" and a password of your e-mail address. After
> > logging in, type "cd internet-drafts" and then
> > "get draft-ietf-ltans-ers-09.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> > 	mailserv <at> ietf.org.
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-ltans-ers-09.txt".
> >
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
Permalink | Reply | 0 comments |
headers
Denis Pinkas | 11 Jan 2007 11:20
Picon

Re: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd


Nearly no comments were sent on the LTANS mailing list on these documents. 
It may be questionable why. The fact is that these documents are badly written, 
and thus it takes an enormous amount of time to attempt to understand them. 

Even though, most readers will fail, but will not dare to report that they did. 
I am unsure that I understood them, but I dare to report it.

This draft and its companion documents namely draft-ietf-ltans-ari-00 and 
draft-ietf-ltans-validate-00 raise a number of questions to be solved.
Let us look now at the details of ERS.

No ASN.1 compiler has been used to validate the syntax, otherwise, 
it would have been noticed that there is an obvious ASN.1 error on EvidenceRecord.

   EvidenceRecord ::= SEQUENCE {
      version                   INTEGER { v1(1) } ,
      digestAlgorithms          SEQUENCE OF AlgorithmIdentifier,
      cryptoInfos               [0] CryptoInfos OPTIONAL,
      encryptionInfo            [1] EncryptionInfo OPTIONAL,
      archiveTimeStampSequence  ArchiveTimeStampSequence,
      ...
      }

Later on the text defines ArchiveTimeStampSequence as:

   ArchiveTimeStampSequence ::= SEQUENCE OF
                                ArchiveTimeStampChain
and 

   ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp

and

   ArchiveTimeStamp ::= SEQUENCE {
     digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
     reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL,
     timeStamp       ContentInfo}

   PartialHashtree ::= SEQUENCE OF OCTET STRING

Note that this information is spread all around the document, 
rather than presented in sequence which does not ease its reading.

ContentInfo is supposed to carry a TST. This means that timeStamp 
should be defined as TimeStampToken rather than ContentInfo.

There is no explanation in section 4.1 (top of page 11) to know on which data the digest 
contained in the TimeStampToken is computed. 

If another kind of time-stamp token would need to be carried, the syntax 
would need to be changed. This comes into contradiction with the following sentence :

   Other types of timestamp MAY be used, if they contain time data,
   timestamped data and a cryptographically secure confirmation from the
   TSA of these data.

CryptoInfos from EvidenceRecord should be suppressed, since it is not proven 
that this additional item will ever be useful: encryption techniques may be different 
for each data item and thus cannot apply globally at the level of an EvidenceRecord.
EncryptionInfo should be suppressed too. No interoperability can be obtained on 
these two fields using this specification.

ArchiveTimeStampSequence is a sequence of ArchiveTimeStampChain which is itself 
a sequence of ArchiveTimeStamp. However, there is no way to make a difference between 
an ArchiveTimeStampChain and an ArchiveTimeStampSequence. 

If within an EvidenceRecord, one element within of an archiveTimeStampSequence 
is suppressed (e.g. a ArchiveTimeStamp) this is not detectable. What is the real value 
of the EvidenceRecord structure ? One would expect that an EvidenceRecord includes 
a time stamp. However, it does not not.

The current draft does not allow to apply the processing recursively. Having constructed 
one EvidenceRecord (that would include a time stamp), it is currently not possible to construct 
another one using a previous one. 

This document is supposed to apply to a long term archive service. However, there is no signature 
from an archive service. The TSA should not be confused with a Archive Authority. With the current 
structure the Archive service may not be held responsible of the storage of the data.

The draft claims to protect against weak algorithms or keys. However, it does not make 
a clear and clean separation between the cases of :

-	the key of a Time-Stamping Unit has been compromised,
-	an asymmetric algorithm has been broken for a given key size,
-	a hash algorithm exhibits collisions.

With “Timestamp renewal” the text omits to say that it is necessary using “out of bands 
means” that a given key from a Time Stamping Unit has been compromised or a that given 
asymmetric algorithm has been broken for a given key size.

“Hash-Tree renewal” would apply when hash algorithm exhibits collisions. However a complete 
reconstruction is needed and it is not clearly explained which data from the previous structure 
may re-used.

Appendix A contains an annex and it is not said whether it is informative or normative.
Nevertheless, the benefits of the inclusion of an EvidenceRecord as an unsigned attribute 
are not explained. The advantages and drawbacks of each case is not explained either.

CONCLUSION

In my opinion, none of these documents is ready to be sent to the IESG and 
it does not make sense to send ERS alone. The usefulness of the whole work 
is very questionable. These documents are not mature and contain numerous typos.

The primary question is : “ Is this work really needed ?”. SC 27 has issued ISO 18014-3: 
“Time-stamp services. Mechanisms producing linked tokens” that is very close.

It would be interesting that the authors position their documents towards 
the ISO standard. Duplication of work should be avoided. If there is no duplication, 
then this should be explained in an informative annex. If no acceptable explanations 
may be given, then this work should be stopped.

P.S. I spent several hours to read the documents and to write this message, 
        but I do not have the time available to sustain long discussions on that topic.

Denis

>Hello dear SMIME WG,
>
>at the last meeting of the LTANS WG in San Diego, Russ recommended to
>ask your WG for a cross review of the ERS draft in its final stage (it
>is currently in WGLC). 
>
>http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-09.txt 
>
>It would be nice if some of you could read the draft, review it and
>provide your feedback. 
>
>(As probably most of you already know the draft is about the data
>structure for an Evidence Record to ensure and protect integrity of data
>and signatures even when the algorithms used at signing time become
>insecure at a later point in time.)
>
>WG Last Call runs until January 23rd. 
>If some of you need longer, please send me a note about how much time
>you need. 
>
>Thank you very much for your help, Tobias
>Chair of LTANS
>
>
>
>> -----Original Message-----
>> From: Tobias Gondrom
>> Sent: Tuesday, January 09, 2007 8:12 PM
>> To: ietf-ltans <at> imc.org
>> Cc: 'Carl Wallace'
>> Subject: WG Last Call: draft-ietf-ltans-ers-09.txt - until Jan 23rd
>> Importance: High
>> 
>> Hello dear LTANS WG,
>> 
>> with the small adjustments made in version-9, based on the discussion
>at
>> the meeting in San Diego, I again initiate the formal final WG last
>call.
>> (Hopefully this time it will really be the last one ;-) )
>> 
>> Additionally I will also ask the SMIME WG for cross review of the
>draft as
>> it has been discussed and decided at the last meeting in San Diego.
>> 
>> WG Last Call closes on January 23rd. After which the revised document
>will
>> hopefully be ready for submission to the IESG.
>> 
>> Thank you, Tobias
>> 
>> 
>> Ps.: btw. the ltans-reqs document passed the IETF Last Call and is now
>in
>> its final preparation phase by the IETF editor team.
>> 
>> 
>> 
>> > -----Original Message-----
>> > From: owner-ietf-ltans <at> mail.imc.org [mailto:owner-ietf-
>> ltans <at> mail.imc.org]
>> > On Behalf Of Internet-Drafts <at> ietf.org
>> > Sent: Friday, January 05, 2007 12:50 AM
>> > To: i-d-announce <at> ietf.org
>> > Cc: ietf-ltans <at> imc.org
>> > Subject: I-D ACTION:draft-ietf-ltans-ers-09.txt
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> > directories.
>> > This draft is a work item of the Long-Term Archive and Notary
>Services
>> > Working Group of the IETF.
>> >
>> > 	Title		: Evidence Record Syntax (ERS)
>> > 	Author(s)	: R. Brandner, et al.
>> > 	Filename	: draft-ietf-ltans-ers-09.txt
>> > 	Pages		: 29
>> > 	Date		: 2007-1-4
>> >
>> > In many scenarios, users must be able prove the existence and
>> >    integrity of data, including digitally signed data, in a common
>and
>> >    reproducible way over a long and possibly undetermined period of
>> >    time.  This document specifies the syntax and processing of an
>> >    Evidence Record, a structure designed to support long-term non-
>> >    repudiation of existence of data.
>> >
>> > A URL for this Internet-Draft is:
>> > http://www.ietf.org/internet-drafts/draft-ietf-ltans-ers-09.txt
>> >
>> > To remove yourself from the I-D Announcement list, send a message to
>> > i-d-announce-request <at> ietf.org with the word unsubscribe in the body
>of
>> > the message.
>> > You can also visit
>https://www1.ietf.org/mailman/listinfo/I-D-announce
>> > to change your subscription settings.
>> >
>> > Internet-Drafts are also available by anonymous FTP. Login with the
>> > username "anonymous" and a password of your e-mail address. After
>> > logging in, type "cd internet-drafts" and then
>> > "get draft-ietf-ltans-ers-09.txt".
>> >
>> > A list of Internet-Drafts directories can be found in
>> > http://www.ietf.org/shadow.html
>> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> >
>> > Internet-Drafts can also be obtained by e-mail.
>> >
>> > Send a message to:
>> > 	mailserv <at> ietf.org.
>> > In the body type:
>> > 	"FILE /internet-drafts/draft-ietf-ltans-ers-09.txt".
>> >
>> > NOTE:	The mail server at ietf.org can return the document in
>> > 	MIME-encoded form by using the "mpack" utility.  To use this
>> > 	feature, insert the command "ENCODING mime" before the "FILE"
>> > 	command.  To decode the response(s), you will need "munpack" or
>> > 	a MIME-compliant mail reader.  Different MIME-compliant mail
>readers
>> > 	exhibit different behavior, especially when dealing with
>> > 	"multipart" MIME messages (i.e. documents which have been split
>> > 	up into multiple messages), so check your local documentation on
>> > 	how to manipulate these messages.
>> >
>> > Below is the data which will enable a MIME compliant mail reader
>> > implementation to automatically retrieve the ASCII version of the
>> > Internet-Draft.
Permalink | Reply | 0 comments |
headers
Carl Wallace | 11 Jan 2007 13:59
Favicon

RE: Cross review of draft ERS from LTANS WG - RE: WG Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd

Comments inline...

> From: Denis Pinkas [mailto:denis.pinkas <at> bull.net]
> Subject: Re: Cross review of draft ERS from LTANS WG - RE: WG
> Last Call: draft-ietf-ltans-ers-09.txt- until Jan 23rd
>
>
> Nearly no comments were sent on the LTANS mailing list on
> these documents.

There is just one document that has been submitted for working group last call.

> It may be questionable why. The fact is that these documents
> are badly written, and thus it takes an enormous amount of
> time to attempt to understand them.
>
> Even though, most readers will fail, but will not dare to
> report that they did.
> I am unsure that I understood them, but I dare to report it.
>
> This draft and its companion documents namely
> draft-ietf-ltans-ari-00 and draft-ietf-ltans-validate-00
> raise a number of questions to be solved.

These two drafts were prepared quickly in advance of the last working group meeting.  During the meeting, a call was made for additional co-authors to help clarify and complete the documents.  One person has joined Tobias in this effort but no follow-up drafts have been released yet.

> Let us look now at the details of ERS.
>
> No ASN.1 compiler has been used to validate the syntax,
> otherwise, it would have been noticed that there is an
> obvious ASN.1 error on EvidenceRecord.

The ASN.1 was changed as a result of comments during the previous working group last call.  Minor errors can be corrected without much cause for alarm.  I assume in this case you are referring to the missing 's' at the end of EncryptionInfo.  Also, the id-EvidenceRecord-Internal and id-EvidenceRecord-External values are missing OBJECT IDENTIFIER. 

>
>    EvidenceRecord ::= SEQUENCE {
>       version                   INTEGER { v1(1) } ,
>       digestAlgorithms          SEQUENCE OF AlgorithmIdentifier,
>       cryptoInfos               [0] CryptoInfos OPTIONAL,
>       encryptionInfo            [1] EncryptionInfo OPTIONAL,
>       archiveTimeStampSequence  ArchiveTimeStampSequence,
>       ...
>       }
>
> Later on the text defines ArchiveTimeStampSequence as:
>
>    ArchiveTimeStampSequence ::= SEQUENCE OF
>                                 ArchiveTimeStampChain and
>
>    ArchiveTimeStampChain ::= SEQUENCE OF ArchiveTimeStamp
>
> and
>
>    ArchiveTimeStamp ::= SEQUENCE {
>      digestAlgorithm [0] AlgorithmIdentifier OPTIONAL,
>      reducedHashtree [1] SEQUENCE OF PartialHashtree OPTIONAL,
>      timeStamp       ContentInfo}
>
>    PartialHashtree ::= SEQUENCE OF OCTET STRING
>
> Note that this information is spread all around the document,
> rather than presented in sequence which does not ease its reading.
>
> ContentInfo is supposed to carry a TST. This means that
> timeStamp should be defined as TimeStampToken rather than ContentInfo.

timeStamp was defined as a ContentInfo to allow a type other than TimeStampToken to be used. 

>
> There is no explanation in section 4.1 (top of page 11) to
> know on which data the digest contained in the TimeStampToken
> is computed.

This info appears in Section 4 (middle of page 10): "The root hash value, which represents unambiguously all data objects, is timestamped."

>
> If another kind of time-stamp token would need to be carried,
> the syntax would need to be changed. This comes into
> contradiction with the following sentence :
>
>    Other types of timestamp MAY be used, if they contain time data,
>    timestamped data and a cryptographically secure
> confirmation from the
>    TSA of these data.

See above.

>
> CryptoInfos from EvidenceRecord should be suppressed, since
> it is not proven that this additional item will ever be
> useful: encryption techniques may be different for each data
> item and thus cannot apply globally at the level of an EvidenceRecord.
> EncryptionInfo should be suppressed too. No interoperability
> can be obtained on these two fields using this specification.

This comment was made during a previous last call and resulted in Tobias' posting to the list a few instances of structures that could be conveyed in these fields.  These could be defined in a peer document or defined in this draft.

 
> ArchiveTimeStampSequence is a sequence of
> ArchiveTimeStampChain which is itself a sequence of
> ArchiveTimeStamp. However, there is no way to make a
> difference between an ArchiveTimeStampChain and an
> ArchiveTimeStampSequence.

The two are not used interchangably.  Why is this a problem?
 
> If within an EvidenceRecord, one element within of an
> archiveTimeStampSequence is suppressed (e.g. a
> ArchiveTimeStamp) this is not detectable. What is the real
> value of the EvidenceRecord structure ? One would expect that
> an EvidenceRecord includes a time stamp. However, it does not not.

Why would one element be suppressed?  What would you want to have happen in this case?  As-is, verification would fail.  I have commented previously that it might be better if the chain supported shallow verification, which would enable you to suppress a contiguous set of elements from the beginning of the chain up to the point from which verification was desired.  There was no support for making a change along these lines, and there seemed to be no real need to have this feature. 

What do you mean the EvidenceRecord does not include a timestamp?  It includes ArchiveTimeStampSequence, which may have one or more timestamps.

 
> The current draft does not allow to apply the processing
> recursively. Having constructed one EvidenceRecord (that
> would include a time stamp), it is currently not possible to
> construct another one using a previous one.

An EvidenceRecord is a wrapper around an ArchiveTimeStampSequence.  The draft describes how to add additional ArchiveTimeStamps to the last ArchiveTimeStampChain in an ArchiveTimeStampSequence as well as how to add a new ArchiveTimeStampChain to the ArchiveTimeStampSequence.  I don't disagree that trying to follow discussion of these three similarly-named structures is difficult, but have failed to come up with clearer alternative suggestions. 

 
> This document is supposed to apply to a long term archive
> service. However, there is no signature from an archive
> service. The TSA should not be confused with a Archive
> Authority. With the current structure the Archive service may
> not be held responsible of the storage of the data.

This document defines a syntax for representing a chain of cryptographic evidence.  This syntax may be used by an archive service.  However, no archive service is required to produce an evidence record.  Archive service signatures are addressed in the context of a protocol for interacting with an archive service.

 
> The draft claims to protect against weak algorithms or keys.
> However, it does not make a clear and clean separation
> between the cases of :
>
> -     the key of a Time-Stamping Unit has been compromised,
> -     an asymmetric algorithm has been broken for a given key size,
> -     a hash algorithm exhibits collisions.
>
> With "Timestamp renewal" the text omits to say that it is
> necessary using "out of bands means" that a given key from a
> Time Stamping Unit has been compromised or a that given
> asymmetric algorithm has been broken for a given key size.

This should be clarified.

>
> "Hash-Tree renewal" would apply when hash algorithm exhibits
> collisions. However a complete reconstruction is needed and
> it is not clearly explained which data from the previous
> structure may re-used.
>
> Appendix A contains an annex and it is not said whether it is
> informative or normative.
> Nevertheless, the benefits of the inclusion of an
> EvidenceRecord as an unsigned attribute are not explained.
> The advantages and drawbacks of each case is not explained either.

Good point.

>
> CONCLUSION
>
> In my opinion, none of these documents is ready to be sent to
> the IESG and it does not make sense to send ERS alone. The
> usefulness of the whole work is very questionable. These
> documents are not mature and contain numerous typos.

We should not cloud the review of ERS by referring to typos in -ari and -validate.
 
> The primary question is : " Is this work really needed ?". SC
> 27 has issued ISO 18014-3:
> "Time-stamp services. Mechanisms producing linked tokens"
> that is very close.
>
> It would be interesting that the authors position their
> documents towards the ISO standard. Duplication of work
> should be avoided. If there is no duplication, then this
> should be explained in an informative annex. If no acceptable
> explanations may be given, then this work should be stopped.

The ISO drafts have been discussed on the list and are referenced by this document as a source for alternative timestamp formats.

>
> P.S. I spent several hours to read the documents and to write
> this message,
>         but I do not have the time available to sustain long
> discussions on that topic.

Thanks for the review.

>
> Denis
>

Permalink | Reply | 0 comments |

Gmane