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

From: "Jim Schaad" <[email-masked]>
Date: Tue, 4 Apr 2006 20:47:09 -0700

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Thursday, March 30, 2006 6:59 AM
> To: [email-masked]
> 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 
> >[email-masked] 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:
> >	[email-masked].
> >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:	<[email-masked]>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-ietf-smime-escertid-00.txt
> 
> 
> 
>