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

As far as I remember PKIX only has exchanges some message with several 
syntactical
proposals for an attributs, some of them broken, but not talked about the
semantics, or what to do in relation with the surrounding signature 
attribute.
The last seems to me an interesting thing, but it should be done top down,
i.e. what do we really want to signal with this attribute.

Question: As soon as the signature hash algo becomes something like sha256
is there any benefit to use another hash algorithm in some 'id attribute'?

Question: What should be the default value of a hash algorithm, note that
I don't talk about defining it in ASN.1 as DEFAULT something. The field
can be marked OPTIONAL so that it can can easily default to
a value with or without the NULL parameter. 

Furthermore, we have then at least two possible interpretations of an 
absent alog.
1 - A fixed value like sha256
2 - the same as in the signature (or some more elaborated rule like
 if hash length > 160 bits then identical to the sign alg else sha1

Question: If one changes the existing definition of ESSCertid to use
2 above, would this hurt existing implementations to an unacceptable
way, i.e. how many RSA+sha256 signature certs have been deployed.

Question: How much time is necessary to fix the existing software which
is technically already prepared to use sha256 in signatures but not in 
ESSCertIds.
The day this has been agreed and months before the RFC is out? :-)
> So, it would make sense to have SHA-256 as the default algorithm 
> for the new structure.
>   
Not necssarily.
> 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.
>   
And it it is sha512+RSA, then one needs to indicate the algo? What make 
sha256
so important that it can be a default?
> 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.
>   
If you recommend that the ESSCertid SHOULD contain the IssuerSerial then it
is probably a bit more difficult to create a a true fake cert that not 
only has a proper
ASN.1 encoding, a proper signature, and also a forced issuer name and a 
seriual number.
> F

--
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

smime.p7s
Description: S/MIME Cryptographic Signature