Hello Susanne, yes, I think it should be sufficient to give an example of current constraints in the draft. We could also define an OID e.g. to define specific constraints: OID for "larger key is always more secure than less" What other constraints do you have in mind? Tobias > -----Original Message----- > From: owner-ietf-ltans@xxxxxxxxxxxx [mailto:owner-ietf-ltans@xxxxxxxxxxxx] > On Behalf Of Susanne Okunick > Sent: Tuesday, September 04, 2007 12:29 PM > To: ietf-ltans@xxxxxxx > Subject: draft-ietf-ltans-dssc-00 comments --constraints-- > > Hello, > > for now we could define current constraints for public key algorithm and > give a guidance how to process/interprete them. A guidance may be: a > modulus (for RSA) greater than 1024 is as suitable as the modulus 1024 > itself. > > But what about algorithms that are unknown till now? If an algorithm > occurs as recently as in the future someone else has to define the new > constraints, e. g. the publisher of a policy, expert committees or even > a new RFC. > > Advantage for giving a definition: On the basis of the draft the > operator/user is directly able to write/interpret a policy. But: Perhaps > it suffices only to give an example for current contraints in this > draft. > > What do you think about this problem? > > Best regards > Susanne Okunick > > -- > ___________________________________________________________ > > Dipl.-Math.(FH) Susanne Okunick > Fraunhofer Institute for Secure Information Technology > Department Transaction and Document Security > Rheinstraße 75, 64295 Darmstadt, Germany > phone ++49 / (0)6151 869 60005, fax ++49 / (0)6151 869 322 > homepage: http://www.sit.fraunhofer.de > ___________________________________________________________
Attachment:
smime.p7s
Description: S/MIME cryptographic signature