Hi Susanne, answers inline. - Tobias > -----Original Message----- > From: Susanne Okunick [mailto:susanne.okunick@xxxxxxxxxxxxxxxxx] > Sent: Monday, September 10, 2007 4:00 PM > To: Tobias Gondrom > Cc: ietf-ltans@xxxxxxx > Subject: RE: draft-ietf-ltans-dssc-00 comments --constraints-- > > Hi Tobias, > > > Hello Susanne, > > > > yes, I think it should be sufficient to give an example of current > > constraints in the draft. > We will pick up an example like this in our draft. That's great. > > We could also define an OID e.g. to define specific constraints: > > OID for "larger key is always more secure than less" > We are thinking about this issue... we don't think, that OIDs are > satisfying solution, because of bad readability. Hm, at the moment I can't even think of other constraints than "larger key size". As an alternative to constraints, dssc could also list all algorithm parameters it knows (refering to algorithmIdentifier) and leave the decision about deductions from this information to the verification application. > > What other constraints do you have in mind? > I meant constraints that are currently not known and evaluated for the > first time in the future. For such contraints we cannot give a > definition now. Ok, obviously. (Personal comment: Don't worry too much about the unknown. ;-) ) (See also comment on using constraints in future verification applications.) > > Susanne and Thomas > > > > 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 > > > ___________________________________________________________ > -- > ___________________________________________________________ > > 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 > ___________________________________________________________ > > The electronic Signature is certified by the Fraunhofer CA: > http://pki.fraunhofer.de/FhG-CA-Certs/FhG-CA_v2_cert.der > ___________________________________________________________
Attachment:
smime.p7s
Description: S/MIME cryptographic signature