Subject: [secdir] Review of draft-ietf-pkix-rfc4055-update-01

From: Tero Kivinen <[email-masked]>
Date: Fri, 16 Jan 2009 12:04:54 +0200

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document updates RFC4055 "Additional Algorithms and Identifiers
for RSA Cryptography for use in the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL)
Profile" by changing one SHOULD to MUST NOT for algorithm parameters
in an X.509 certificate's subjectPublicKeyInfo field.

I am not completely sure if the Security Considerations section is
enough. Now it says:

   The security considerations from [RFC4055] apply. No new security 
   considerations are introduced. 

but considering that this moves some bits away from the certificate
and says that they should be negotiated in protocols that need to
employ certificates, this might create new security issues, i.e. it
might put some more emphasis on the security of the protocol used to
negotiate those parameters.

I do not really know enough, about what kind of parameters there are
to be negotiated in the protocols employing certificates, to know if
this is really the case. Perhaps someone who is understands better
what is moved here, should look this issue.
-- 
[email-masked]
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Sean Turner <[email-masked]>
Date: Thu, 29 Jan 2009 07:42:32 -0500

> what is moved here, should look this issue.

I'm thinking about the S/MIME context where recipients advertise their 
capabilities with the SMIME Capability attribute and the originator 
either supports them or it doesn't.  So maybe "negotiate" isn't the best 
word but - how about we add the following to the Security Considerations 
section:

"If the RSAES-OAEP-params are negotiated, then the negotiation mechanism 
needs to provide integrity for these parameters.  For example, an S/MIME 
Agent can advertise their capabilities in the SMIMECapabilities 
attribute, which is either signed attribute [RFC3851bis] or a 
certificate extension [RFC4262]."

I'd need to add informative references for RFC3851bis and RFC4262.

spt

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 30 Jan 2009 12:50:27 +0200

> certificate extension [RFC4262]."

That would address my concern.
-- 
[email-masked]
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir