|
RE: I-D ACTION:draft-ietf-smime-escertid-00.txt
2006-04-05 19:02:18
Denis,
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Denis
Pinkas
Sent: Wednesday, April 05, 2006 6:32 AM
To: ietf-smime(_at_)imc(_dot_)org; Jim Schaad
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Jim,
After more thoughs and exchange of arguments I am inclined to
accept your position.
I believe that the rule should be:
if SHA-1 is used, then ESSCertID MUST be used.
I would totally agree with this wording.
So, it would make sense to have SHA-256 as the default
algorithm for the new structure.
In this thread, some people advocated implicit signaling of
the algorithm.
It made me think that we should provide some additional
guidance for implementors. For example, if SHA-256 with RSA
is the signature algorithm, then it would make sense, *not*
to use ESSCerID :-) but rather to use the new structure with SHA-256.
Now, the case where SHA-1 with RSA is the signature algorithm
is more complicated. ESSCertID should be used. Should we, in
addition, recommend to use the new structure with SHA-256 ?
It would not hurt, but in case
SHA-1 is broken, does it really provide additional security ?
I leave the floor open to cryptographers.
Finally, I have a minor naming problem: what is it called
ESSCertIDEx and not ESSCertIDv2 ? What means "Ex" ?!?
I have no problems with this change in the name of the structure. The use
of Ex shows the time that I used to work at Microsoft, Ex stands for
Extended and was applied to system API calls.
Jim
I would rather prefer ESSCertIDv2 which is more meaningful
without any explanation.
Denis
Denis,
I am well aware that the issue was debated on the PKIX mailing list,
and I ignored it because it was not of immediate importance
to me at the time.
I am not sure that I agree that the PKIX proposal is really
backwards
compatable. What can be said is that if you use it in a specific
manner then it produces the same bits on the wire, however consider
what the reality of things is.
In the S/MIME world the new structure is identified by a new
OID, thus
an old client would see that there is an attribute that it
does not understand.
This means that the new structure is really backwards
compatable, if an
old client gets a message from a new client the item is
ignored and the
old client can successfully process the message. Likewise if an old
client sends a message and includes this attribute the new client
should still understand and process the extension correctly. (This
would also be true with the timestamp protocol in RFC 3161.)
Now lets look at what happens with this in RFC 3029 if you simply
replace ESSCertID with your proposed ESSCertIDEx. If an old client
sends a message to the new client, it works since the new
client can correctly decode it.
If a new client sends a message to an old client, it MUST
use the SHA-1
hash algorithm as any other would cause the old client to
have a decode
algorithm. But it is not clear that the new client can recognize in
advance that it is dealing with an old client so it would ALWAYS use
SHA-1 just in case. TO me this means that you might as well
not change the protocol.
(Side note - there is not versioning in the low level
structures that I
could see. If you update the version number then there is
no problem
with changing the structure itself.
There is some logic to the argument that was put forward by
Peter that
having the same effective structure would allow for writing
of a single
decode/encode routine and thus potentially save code space.
I personally think that we should be moving out of SHA-1 and
onto SHA-2
in the standards as quickly as possible. If I belive this
then I need
to take the position that either 1) size is not an issue or
2) the defaults should
be the algorithms that we think should be used in the
immediate future. I
am a strong supporter of option 2.
I will look at your suggested re-write as part of the up-coming
revision of the document.
jim
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Denis
Pinkas
Sent: Thursday, March 30, 2006 6:59 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: I-D ACTION:draft-ietf-smime-escertid-00.txt
Jim, and the working group
1 - This topic has been debated on the PKIX mailing list and a
proposal has been made. The proposed ASN.1 structure
is different
from the one described in draft-ietf-smime-escertid-00.txt.
The current ASN.1 in RFC 2634 is:
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
The proposal from draft-ietf-smime-escertid-00.txt is:
ESSCertIDEx ::= SEQUENCE {
certHash Hash,
hashAlg AlgorithmIdentifier
DEFAULT {id-sha256},
issuerSerial IssuerSerial OPTIONAL
}
The proposal made on the PKIX mailing list is:
ESSCertIDv2 ::= SEQUENCE {
certHash OCTET STRING,
issuerSerial IssuerSerial,
hashAlgorithm AlgorithmIdentifier DEFAULT { sha-1 }
The advantage of the last proposal is backward
compatibility with the
existing structure. The disadvantage is that it is less "natural"
than invented from scratch, but some explanations can
easily overcome
this drawback.
I would propose to adopt the proposal made on the PKIX
mailing list.
In addition, I would take advantage of the rewriting of
this section
to correct some past "errors" in section 5.4.1.
2 - Proposed rewritting:
"5.4.1. Certificate Identification
The best way to identify certificates is an
often-discussed issue.
When an issuer/serial number pair is included in the SignedData
object, that information is not part of the message digest
calculation process may thus be changed without being detected.
That information may only be used as an hint and by
itself, does
not allow to make sure that the right certificate is being
accessed.
A hash of the entire certificate allows a verifier to
verify that
the certificate that was chosen by the signer is being
used when
the
signature is verified. It permits a detection of certificate
substitution attacks.
Duplication of the issuer/serial number pair within the Signing
Certificate attribute is not fully necessary, but has the
advantage to get the whole information from that attribute.
Attribute certificates and additional public key certificates
containing authorization information do not have an
issuer/serial
number pair represented anywhere in a SignerInfo object. When an
attribute certificate or an additional public key
certificate is
not
included in the SignedData object, it becomes much more
difficult
to
get the correct set of certificates based only on a hash of the
certificate. For this reason, these certificates SHOULD be
identified
by the IssuerSerial object."
3 - It is a matter of taste, but I would rather prefer:
SigningCertificatev2 instead of SigningCertificateEx
4 - It would be nice to correct the typos from RFC 2634, e.g.
"requred".
There are other typos like: "certficates", "subsiquent",
"Indentification", ...
Please use a spell checker.
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 : ESS Update: Adding CertID Algorithm Agility
Author(s) : J. Schaad
Filename : draft-ietf-smime-escertid-00.txt
Pages : 18
Date : 2006-3-24
In the original Enhanged Security Services for S/MIME draft, a
structure for cryptographically linking the certificate to
be used in
validation with the signature was introduced, this structure was
hardwired to use SHA-1. This document allows for the
structure to have
algorithm agility and defines new attributes to deal with
the updating.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-escertid-00.txt
To remove yourself from the I-D Announcement list, send a
message to
i-d-announce-request(_at_)ietf(_dot_)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-escertid-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(_dot_)org(_dot_)
In the body type:
"FILE /internet-drafts/draft-ietf-smime-escertid-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-3-24165058(_dot_)I-D(_at_)ietf(_dot_)org>
ENCODING mime
FILE /internet-drafts/draft-ietf-smime-escertid-00.txt
Denis Pinkas
|
|