Re: [pkix] Fwd: Last Call: draft-schaad-pkix-rfc2875-bis-03.txt (Diffie-Hellman Proof-of-Possession Algorithms) to Proposed Standard
The text states: The reasoning behind doing POP can be found in Appendix C in [CRMF]. Appendix C from [CRMF] states: POP for key management keys: Similarly, POP for key management keys (that is, keys used for either key agreement or key exchange) can help to prevent undermining confidence in the PKI. Suppose that Al is a new instructor in the Computer Science Department of a local university. Al has created a draft final exam for the Introduction to Networking course he is teaching. He wants to send a copy of the draft final to Dorothy, the Department Head, for her review prior to giving the exam. This exam will of course be encrypted, as several students have access to the computer system. However, a quick search of the certificate repository (e.g., search the repository for all records with subjectPublicKey=Dorothy's-value) turns up the fact thatseveral students have certificates containing the same public key management key as Dorothy. At this point, if no POP has been done by the CA, Al has no way of knowing whether all of the students have simply created these certificates without knowing the corresponding private key (and thus it is safe to send the encrypted exam to Dorothy), or whether the students have somehow acquired Dorothy's private key (and thus it is certainly not safe to send the exam). Thus, the service to be provided by the PKI allowing users to communicate with one another, with confidence in who they are communicating with, has been totally defeated. If the CA is providing POP, then either no students will have such certificates, or Al can know with certainty that the students do indeed know Dorothy's private key, and act accordingly. I do not believe that refering to this text is adequate nor sufficient. A real explanation, in the context of DH key exchange, is necessary, Denis Some on this list might be interested about this draft. Please send any comments to ietf@ietf.org. spt Original Message Subject: Last Call: draft-schaad-pkix-rfc2875-bis-03.txt (Diffie-Hellman Proof-of-Possession Algorithms) to Proposed Standard Date: Wed, 05 Dec 2012 14:08:01 -0800 From: The IESG iesg-secret...@ietf.org Reply-To: ietf@ietf.org To: IETF-Announce ietf-annou...@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Diffie-Hellman Proof-of-Possession Algorithms' draft-schaad-pkix-rfc2875-bis-03.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of-possession rather than general purpose signing. This document obsoletes RFC 2875. The file can be obtained via http://datatracker.ietf.org/doc/draft-schaad-pkix-rfc2875-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-schaad-pkix-rfc2875-bis/ballot/ No IPR declarations have been submitted directly on this I-D. ___ pkix mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pkix
RE: [pkix] Last Call: draft-ietf-pkix-rfc5280-clarifications-08.txt
To the IESG, I am making an appeal to the IESG from the decision of Steve Kent one of the co-chairs of the PKIX WG to send back the document draft-ietf-pkix-rfc5280-clarifications-10.txt to the IESG. This decision has not even been taken in agreement with the other PKIX co-chair Stefan Santesson, since he posted a message on October 19 to the PKIX list saying: The current text requires me to reject a CRL as source of revocation information if ANY entry includes an unrecognised extension. So thinking as an implementer, I just wander how this works in practice. Consider I have a 100 MB CRL. I then have to go through each entry and determine if any of them have an unrecognised extension before I use it. Just going to the entry of interest is not enough, since another entry may have an unrecognised extension. Is this how implementations work today? This illustrates once again that keeping the current text would be the worse of all the solutions. * **I am asking the IESG to send back the document (update to RFC 5280) to the WG.* When the original last call was placed I sent the following argument: A discussion has just started yesterday on the PKIX mailing list about an Errata in section 5.3 from RFC 5280. At this time it can clearly be seen that RFC 5280 is NOT compatible with X.509 for the processing of crlEntryExtensions, whereas RFC 5280 is supposed to be a *profile* of X.509. For that reason, I ask the IESG to suspend its decision until the issue about crlEntryExtensions is clarified one way or another, since this point now needs to be clarified and will impact a document whose goal is precisely to clarify RFC 5280. My request has been accepted and the WG has worked in order to attempt to solve the issue. Several people tried to propose text to fix the current text, while some others were providing arguments to say that the text was not good enough but did not proposed an alternative text proposal. The last exchanges, when attempting to correct the processing of CRL entry extensions in RFC 5280, are the following: On October 5, Denis Pinkas (i.e. myself) made a new strawman proposal, using a text proposed by Steve Kent. On October 9, 2012, Russ Housley replied to Denis Pinkas saying that he had arguments against this text. On October 11, without leaving me the time to reply to Russ, Steve Kent asked Peter Yee to remove the Section 4 text from 5280bis and publish version -10. In my opinion, Russ Housley has not spent sufficient time to read my proposal since his arguments did not take into consideration my proposed text. Usually a two weeks interval is given by the chairs before making a decision. In this case, it has been *two days*, without any warning. I believe this is unfair. The two co-chairs should have remembered to the WG participants (including Russ Housley as PKIX WG participant) how to address strawman proposals: everyone is allowed to critize a strawman proposal, as long as he provides technical arguments for what he believes is incorrect, and also attempts to build a new strawman proposal using as much as possible the previous one. This is one of the explanations (but not the single one) why the PKIX WG is now unable to reach consensus. The co-chairs should act as facilitators. They have been too often taking advantage of their chair hat while defending their own arguments or their own text. If this appeal is rejected, the text from RFC 5280 will stay as it is, but it is incorrect. Sharon Boeyen, the editor X.509, confirmed it was incorrect on the PKIX list on August 28, 2012. If the document is sent back the WG, as requested, I believe it would be appropriate to ask to the PKIX co-chairs : (1) to manage the PKIX WG more appropriately, (2) to remember to all the WG participants how to address strawman proposals, and (3) to avoid taking advantage of their chair hat while defending their own arguments or their own text. I believe that the PKIX WG can agree on a minimum text shortly. Having a polished text is even possible, but only if the WG participants are clearly instructed how to deal with strawman proposals. All of this is only in the interest of publishing RFCs with a correct content. Denis Pinkas = The facts (in reverse order): 3) On October 11, 2012, without any pre warning, Steve Kent, one of the co-chairs of the PKIX WG said : The PKIX list has not demonstrated consensus for the CRL entry extension text I suggested, or any other, since Russ sent his message on this topic on 10/3, over a week ago. Consistent with Russ's direction, I have asked Peter Yee to remove the Section 4 text from 5280bis and publish version -10. I have begun preparation of the IESG report for the redacted version of the doc. 2) On October 9, 2012, Russ Housley replied to Denis
RE: [pkix] Last Call: draft-ietf-pkix-rfc5280-clarifications-08.txt (Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) to Proposed St
A discussion has just started yesterday on the PKIX mailing list about an Errata in section 5.3 from RFC 5280. At this time it can clearly be seen that RFC 5280 is NOT compatible with X.509 for the processing of crlEntryExtensions, whereas RFC 5280 is supposed to be a *profile* of X.509. For that reason, I ask the IESG to suspend its decision until the issue about crlEntryExtensions is clarified one way or another, since this point now needs to be clarified and will impact a document whose goal is precisely to clarify RFC 5280. Denis De :The IESG iesg-secret...@ietf.org A : IETF-Announce ietf-annou...@ietf.org Cc :p...@ietf.org Date : 22/08/2012 17:05 Objet : [pkix] Last Call: draft-ietf-pkix-rfc5280-clarifications-08.txt (Updatesto the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) to Proposed Standard Envoyé par :pkix-boun...@ietf.org The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile' draft-ietf-pkix-rfc5280-clarifications-08.txt as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-09-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc5280-clarifications/ballot/ No IPR declarations have been submitted directly on this I-D. ___ pkix mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pkix
Re: [smime] Fwd: Last Call: draft-schaad-smime-algorithm-attribute-03.txt (SignerInfo Algorithm Protection Attribute) to Proposed Standard
I have a few comments about draft-schaad-smime-algorithm-attribute-03.txt:
1) The key question is what should contain the field signatureAlgorithm ?
SignatureAlgorithmIdentifier is defined in section 10.1.2 from RFC 5652:
10.1.2. SignatureAlgorithmIdentifier
The SignatureAlgorithmIdentifier type identifies a signature
algorithm, and it can also identify a message digest algorithm.
Examples include RSA, DSA, DSA with SHA-1, ECDSA, and ECDSA with
SHA-256. A signature algorithm supports signature generation and
verification operations. The signature generation operation uses the
message digest and the signer's private key to generate a signature
value. The signature verification operation uses the message digest
and the signer's public key to determine whether or not a signature
value is valid. Context determines which operation is intended.
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
Some examples are questionable: is RSA really a signature algorithm ?
sha-1withRSA is really a signature mechanism, since it cannot be used for
encryption.
If real signature algorithms were being used in the OID, then half of the
problems mentioned in the draft would disappear.
This case should be mentioned in the draft.
The draft should also recommend the use of signature algorithms using both a
hash function and an asymetric algorithm.
2) We come from a point where, 20 years ago, the same certificate was used for
three purposes:
authentication, non repudiation and encipherment. RSA was the single algorithm
used in practice.
Since then, there are many situations where different certificates are used for
each purpose.
We now should recommend to use real signature algorithms, which mean an OID
specifying
a combination of a hash function and an asymetric cryptographic algorithm.
If a certificate is being used, then an OID specifying the algorithm in the
certificate should be OID
specifying a combination of a hash function and an asymetric cryptographic
algorithm.
When certificates are being used, when the ESSCertID is being used, and when
real signature algorithms are being used
then the new proposed protection attribute is not needed.
The current draft does not mention this possibility.
3) There is another draft under discussion in the PKIX WG called:
draft-ietf-pkix-ocspagility-09.
Although the field certIdentifier below is misnamed, the idea is to say that
for Elliptic Curves we need two parameters
instead of one. This is what the proposed draft is attempting to say:
PreferredSignatureAlgorithm ::= SEQUENCE {sigIdentifier
AlgorithmIdentifier,certIdentifier AlgorithmIdentifier OPTIONAL
}
The syntax of AlgorithmIdentifier is defined in section 4.1.1.2 of RFC
5280 [RFC5280]
sigIdentifier specifies the signature algorithm the client prefers, e.g.
algorithm=ecdsa-with-sha256. Parameters are absent for most common signature
algorithms.
certIdentifier specifies the subject public key algorithm identifier the
client prefers in the server's certificate used to validate the OCSP
response. e.g. algorithm=id-ecPublicKey and parameters= secp256r1.
certIdentifier is OPTIONAL and provides means to specify parameters
necessary to distinguish among different usages of a particular algorithm,
e.g. it may be used by the client to specify what curve it supports for a
given elliptic curve algorithm.
Note the this draft provides a correct example for a signature algorithm
identifier: ecdsa-with-sha256
The draft proposed by Jim should consider the case of OIDs for Elliptic Curves
4) The draft is missing a risk analysis or examples for real possibilities of
substitution.
For the above reasons, I believe that a new draft should be issued.
Denis
--
From : smime-bounces
To : smime
Date : 2010-12-06, 23:43:50
Subject : [smime] Fwd: Last Call: (SignerInfo Algorithm Protection Attribute)
to Proposed Standard
Original Message
Subject: Last Call: draft-schaad-smime-algorithm-attribute-03.txt
(Signer Info Algorithm Protection Attribute) to Proposed Standard
Date: Mon, 06 Dec 2010 14:35:04 -0800
From: The IESG iesg-secret...@ietf.org
To: IETF-Announce ietf-annou...@ietf.org
The IESG has received a request from an individual submitter to consider
the following document:
- 'Signer Info Algorithm Protection Attribute'
draft-schaad-smime-algorithm-attribute-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-03. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-schaad-smime-algorithm-attribute/
IESG discussion can be tracked via
RE: [pkix] Last Call: draft-ietf-pkix-tamp (TrustAnchor ManagementProtocol(TAMP)) toProposed Standard
Carl,
It is clear that we disagree.
The key points are the following:
1) CAs issue self-signed certificates.
2) CAs do NOT place constraints on the usage of theirs self-signed certificates.
These usages are placed OUTSIDE the self-signed certificates by Relying Parties.
The current draft with its current extensions does not allow to manage at the
same time
self-signed certificates and usage conditions for leaf certificates.
In the case of the Web browser model, it would be necessary to add conditions
which apply to the leaf certificate only, namely:
a) EKU, and
b) OIDs of Certification Policies.
In the more general case, it would be advantageous to also add an application
class
so that applications can know which self-signed certificates associated with
usages
that apply to leaf certificates are adequate for them.
Denis
- Message reçu -
De : Carl Wallace
À : denis.pinkas,ietf
Date : 2010-01-29, 14:12:32
Sujet : RE: [pkix] Last Call: draft-ietf-pkix-tamp (TrustAnchor
ManagementProtocol(TAMP)) toProposed Standard
Though weve been through each of these points before responses are inline
From: pkix-boun...@ietf.org [mailto:pkix-boun...@ietf.org] On Behalf Of Denis
Pinkas
Sent: Friday, January 29, 2010 3:19 AM
To: ietf
Cc: pkix
Subject: Re: [pkix] Last Call: draft-ietf-pkix-tamp (TrustAnchor
ManagementProtocol(TAMP)) to Proposed Standard
Carl,
You said: the current protocol is able to accommodate the web browser model
and
does so for the existing path processing constraints defined in RFC 5280, i.e.,
name constraints, certificate policies and certificate policy constraints.
Unfortunately, this is not the case. Applying name constraints, certificate
policies
and certificate policy constraints as defined in RFC 5280 is not sufficient to
accommodate
the web browser model.
The web browser model controls characteristics which only apply to leaf
certificates,
in practice EKU (Extended Key Usages) and OIDs of Certication Policies.
[CW] Certificate policies and policy constraints are fully supported.
EKU is not processed across a certification path so its utility in a TA is
limited.
[DP] EKU should be processed for the leaf certificate.
Independent of TAMP/TAF, the EKU-like mechanism used by some browsers
has been the subject of mailing list posts describing interoperability
problems.
This could be addressed by defining and using a similar extension that has
associated path processing rules. It has also been suggested that the
certificate policies
extension could serve this purpose without defining a new extension.
TAMP is not the place to sort out that issue.
[DP] If TAMP is not the place to slove this issue, then it means that TAMP
should go on the EXPERIMENTAL track.
You claim that this feature could be provided as an extension to the protocol.
[CW] I claim this, have given pointers to similar extensions and have offered
to co-author
or review the new specification.
This is an acknowledgment that the current document does not currently support
the web browser model.
[CW] The use of an EKU extension in a TA is not a different model. Its a
different extension that fits
within the model that has been defined.
The current draft is in fact covering three use cases, none of them is
correctly addressing the web browser model.
Should an extension be defined, it would be difficult to use, since extensions,
as supported in the draft,
mandate to use two separate operations: to set the initial content of a trust
anchor and then to modify it
afwterwards using a TAMPUpdate operation (which is solely able to use
extensions).
[CW] This is not correct. A trust anchor can be added to a trust anchor store
with a full definition (including extensions)
using an add operation. There is no need for a second message simply to set
extensions.
[DP]The current definition ofa TrustAnchorChoice allows to add a structure that
is inappropriate
since it does not allow to support the missing features indicated at the top of
this e-mail or
to add the missing feaures in a single operation.
The initial content of a Trust Anchor is defined by:
TrustAnchorChoice ::= CHOICE {
certificate Certificate,
tbsCert [1] EXPLICIT TBSCertificate,
taInfo [2] EXPLICIT TrustAnchorInfo }
None of these options, include an extension field.
[CW] All of these options include an extensions field:
Certificate.tbsCertificate.extensions, TBSCertificate.extensions,
TrustAnchorInfo.exts.
[DP]The extension field of Certificate cannot be used. See the main comment at
the top of this e-mail.
Only the TAMP update operation includes an extension field:
TBSCertificateChangeInfo ::= SEQUENCE {
serialNumber CertificateSerialNumber OPTIONAL,
signature[0] AlgorithmIdentifier OPTIONAL,
issuer [1] Name OPTIONAL,
validity [2] Validity OPTIONAL,
subject
Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor ManagementProtocol(TAMP)) to Proposed Standard
Carl,
You said: the current protocol is able to accommodate the web browser model
and
does so for the existing path processing constraints defined in RFC 5280, i.e.,
name constraints, certificate policies and certificate policy constraints.
Unfortunately, this is not the case. Applying name constraints, certificate
policies
and certificate policy constraints as defined in RFC 5280 is not sufficient to
accommodate
the web browser model.
The web browser model controls characteristics which only apply to leaf
certificates,
in practice EKU (Extended Key Usages) and OIDs of Certication Policies.
You claim that this feature could be provided as an extension to the protocol.
This is an acknowledgment that the current document does not currently support
the web browser model.
The current draft is in fact covering three use cases, none of them is
correctly addressing the web browser model.
Should an extension be defined, it would be difficult to use, since extensions,
as supported in the draft,
mandate to use two separate operations: to set the initial content of a trust
anchor and then to modify it
afwterwards using a TAMPUpdate operation (which is solely able to use
extensions).
The initial content of a Trust Anchor is defined by:
TrustAnchorChoice ::= CHOICE {
certificate Certificate,
tbsCert [1] EXPLICIT TBSCertificate,
taInfo [2] EXPLICIT TrustAnchorInfo }
None of these options, include an extension field.
Only the TAMP update operation includes an extension field:
TBSCertificateChangeInfo ::= SEQUENCE {
serialNumber CertificateSerialNumber OPTIONAL,
signature[0] AlgorithmIdentifier OPTIONAL,
issuer [1] Name OPTIONAL,
validity [2] Validity OPTIONAL,
subject [3] Name OPTIONAL,
subjectPublicKeyInfo [4] SubjectPublicKeyInfo,
exts [5] EXPLICIT Extensions OPTIONAL }
Using a change function to add information is not the right way to proceed.
The protocol is unable to support the sending of a full description of a trust
anchor,
including the support of extensions, all in a single exchange.
As said in the PKIX list, this can be done in a single step. Proposals have
been posted to demonstrate how it could be done.
It has been responded that the proposal was correctly adressing the issue in
principle, but the editors were not willing
to make a change which was considered as a major change to the initial proposal.
Another major issue for this draft is that it is unable to tell for which usage
(e.g. for which application or which purpose)
each trust anchor may be used.
All these issues led me to propose that this document proceeds on the
EXPERIMENTAL track,
thus leaving room for a STANDARD protocol adressing the needs of the Internet
community
when using X.509 self-signed certificates associated with metadata.
Denis
De : pkix-bounces
À : denis.pinkas,ietf
Date : 2010-01-25, 16:20:06
Sujet : Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor
ManagementProtocol(TAMP)) to Proposed Standard
Denis,
As we have discussed on the PKIX mailing list, the current protocol is able to
accommodate the web browser model and does so for the existing path processing
constraints defined in RFC 5280, i.e., name constraints, certificate policies
and certificate policy constraints. The problem you are referring to is really
with the current EKU extension, which is not processed across a certification
path. Were one to define an EKU variant that has path processing semantics,
TAMP would convey this information just fine. Other specifications have
defined extensions for inclusion in trust anchors to extend the RFC 5280 set,
including RFC 3779 and CCC. Something similar is appropriate for this purpose.
Carl
From: pkix-boun...@ietf.org [mailto:pkix-boun...@ietf.org] On Behalf Of Denis
Pinkas
Sent: Monday, January 25, 2010 3:49 AM
To: ietf
Cc: pkix
Subject: Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor
ManagementProtocol (TAMP)) to Proposed Standard
The current protocol has severe limitations.
They have been pointed during the last call at the PKIX WG level, but the
protocol
has not been modified to address them.The end result has only been to add text
to explain the limitations without removing these limitations.
See section 3: When using these structures without any additional extension,
for which purposes the trust anchor info shall be used to verify
certification paths needs to be locally defined; this means that different
usages for the same or different trust anchors placed in the same TAS
are not possible either.
One way to have different usages for different trust anchors without
using extensions is to use a different TAS for every different usage.
The consequences are as follows:
All web browser providers currently use a different model to manage trust
anchors.
They are able
Re: [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor Management Protocol (TAMP)) to Proposed Standard
The current protocol has severe limitations. They have been pointed during the last call at the PKIX WG level, but the protocol has not been modified to address them.The end result has only been to add text to explain the limitations without removing these limitations. See section 3: When using these structures without any additional extension, for which purposes the trust anchor info shall be used to verify certification paths needs to be locally defined; this means that different usages for the same or different trust anchors placed in the same TAS are not possible either. One way to have different usages for different trust anchors without using extensions is to use a different TAS for every different usage. The consequences are as follows: All web browser providers currently use a different model to manage trust anchors. They are able to associate different key usages for every leaf certificate with any trust anchor (all placed in the same trust anchor store). This can be done in a single operation. Furthermore, with the introduction of EV SSL Certificates (i.e. Extended Validation SSL certificates) the Certification Policy OIDs of leaf certificates that fulfills the requirements of EV SL certificates are added to the trust anchor to which the EV SSL certificate relates. This means that supporting the web browser model mandates to be able to add key usages (e.g. EKU extended key usages) for leaf certificates as well as Certification Policies for leaf certificates. This is not possible with the proposed protocol. As a consequence, the current protocol is unable to accomodate the web browser model. Since the protocol seems to be sufficient for another community (but not to the Internet community), it is proposed to place this document on the EXPERIMENTAL track rather than on the standards track. Denis Date : 2010-01-14, 18:34:14 Sujet : [pkix] Last Call: draft-ietf-pkix-tamp (Trust Anchor Management Protocol (TAMP)) toProposed Standard The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Trust Anchor Management Protocol (TAMP) ' draft-ietf-pkix-tamp-05.txt as a Proposed Standard This document includes a downref to draft-ietf-pkix-new-asn1, which is under consideration by the IESG for publication as an Informational RFC. This document updates ASN.1 modules for PKIX specifications to conform to the 2002 version of ASN.1, but makes no changes to the bits on the wire. The community is specifically requested to consider whether down refs to draft-ietf-pkix-new-asn1 are appropriate in the general case, in addition to the specific case of draft-ietf-pkix-tamp. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-01-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17760rfc_flag=0 ___ pkix mailing list p...@ietf.org https://www.ietf.org/mailman/listinfo/pkix ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-sha2 (Using SHA2 Algorithms withCryptographic Message Syntax) to Proposed Standard
There are obvious errors (intentionnaly left by the editor in order to know how many people read the document). On page 1: The message digest algorithms are defined in and [SHS]. ^^^ Also in section 2.4: 2.4. SHA-512 The SHA-256 message digest algorithm is defined in [SHS]. whereas it should be: 2.4. SHA-512 The SHA-512 message digest algorithm is defined in [SHS]. It would be valuable to explain why DSA cannot be used with SHA-384 and SHA-512. In addition, it is not acceptable to reference in the *normative* references work in progess, i.e.[ECCADD]. The same applies for [SHS]. The text states: NOTE [to be removed upon publication as an RFC]: NIST has not yet finalized FIPS 186-3 and there is a chance that the draft may be changed. This may result in differences between what is documented in the current version of this document and what is in the FIPS. It is intended to synchronize the final version of this draft with the FIPS before publication as an RFC. There is a more substantive comment on the first paragraph of section 1. The text states: If an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in this document. I believe the text should be: If an implementation chooses to support one of the algorithms discussed in this document, then the implementation MUST do so as described in [SHS]. A small discussion in the security considerations section on the advantages (in particular in terms of performances versus security) of using one or another function from the SHA2 family would be helpful. While I welcome this draft, everybody should take into consideration that, if the SHA2 family happens to be broken then we will be at risk. This should be mentioned into the security considerations section. The NESSIE program has evaluated with succces the WHIRLPOOL algorithm. WHIRLPOOL would be a good substitute to SHA-512 and I would encourage that someone drafts an RFC to specify OIDs for using WHIRLPOOL with CMS. Denis The IESG has received a request from the S/MIME Mail Security WG (smime) to consider the following document: - 'Using SHA2 Algorithms with Cryptographic Message Syntax ' draft-ietf-smime-sha2-03.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-03-07. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16033rfc_flag=0 Regards, Denis Pinkas ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) MultipleSigner Clarification) to Proposed Standard
Sam, Denis == Denis Pinkas [EMAIL PROTECTED] writes: Denis Sam, Russ == Russ Housley [EMAIL PROTECTED] writes: Russ Denis: I do not consider these to be new comments. You made Russ them during WG Last Call, and there was considerable Russ discussion on the S/MIME WG mail list. In the end, you were Russ unable to gain any support for your position. Why do you Russ feel I need to respond to the same comments again? I tend to agree with Russ. Denis I do not see how it may be possible to reach a consensus if Denis a dialogue is not accepted. Russ is the editor. You said that you have already brought these issues up in the WG. It is no longer Russ's job to engage with you if he does not want to. You previously said: I strongly suggest that you try and build consensus for these two positions separately. I keep trying. Now you say: It is the WG chairs' job to describe the reasoning for why your comments were rejected during the WG discussion and I've asked the chairs to do that. This does not sound to be a way to try to build consensus for these two positions separately. Am I missing something ? Denis ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) MultipleSignerClarification) to Proposed Standard
The only person who has really engaged the conversation during the last call period was the draft editor, i.e. Russ Housley (who also happens to be a Security Area Director, but in this case he cannot play this role). So it is one against one and Sam is now the single Security Area Director allowed to make a decision. In general the activity on this mailing list is rather low. Silence on the mailing list is rather difficult to interpret. I do not agree with the interpretation Blake made of this silence: it like making the dead peole talk. I cannot understand why Russ is not wishing to try to find a compromise. In the current situation, I believe it t would be fair to have a straw poll on the mailing list and raise the two topics separately. I do not expect many responses. If you agree, I can draft the text of the two questions and propose it to you (i.e. Sam and the co-chairs). Denis OK, let me back up and explain the events as I see them and try to clarify. And I am certainly welcome to any comments or criticism about what my role is or how I should proceed with this. * My job as WG chair is to make sure that the editor (Russ) has created a draft that incorporates what we consider to be the rough consensus of the working group. * You had some comments on this draft. Some of your comments were incorporated. Some of your comments had zero support from the WG members on the working group mailing list. Clarifications welcome as to exactly who else supported these comments. * WG last call closed over a month after your unincorporated comments were made, which allowed plenty of time for anyone to come forward to support your position or for any interested parties to discuss them. * Because of this lack of interest from anyone but yourself, those comments were considered the rough part of rough consensus and were not incorporated. That is, you had something that wasn't working for you, you explained your concern on the mailing list, and no one else shared that concern. * As WG chair, I believe that this was the right way to proceed, Sean as co-chair was in agreement, and the draft progressed out of the working group. Denis Pinkas wrote: You previously said: I strongly suggest that you try and build consensus for these two positions separately. I keep trying. I believe that Sam's recommendation was to take each issue separately and present them clearly to others in the community, and then try to determine what the consensus is about each issue. That is, start a discussion, and based on the outcome of that discussion see where we stood. This didn't happen. Now you say: It is the WG chairs' job to describe the reasoning for why your comments were rejected during the WG discussion and I've asked the chairs to do that. This does not sound to be a way to try to build consensus for these two positions separately. Am I missing something ? I'm willing to accept criticism here, but it's not my job to build the consensus for you. It's my job to determine if an issue has been raised, and to determine if the community has had enough time to review it, and to make sure that the author has incorporated what I believe the consensus to be. * You raised some issues * No one commented on the issues * You escalated the issues * No one commented on the issues * This indicates to me that these issues are only interesting to you, and not to the WG at large, and thus does not reflect the consensus. I mean, I'm not so bold as to say that people are in active disagreement with your position, but I will say that no one cares enough about it to warrant supporting it. So I'm willing to do whatever is required here to make sure that I'm doing my job right, and to make sure that I'm facilitating the creation of high quality drafts. But as far as whether or not your comments have gotten their due consideration from the working group, I will say emphatically that I think they have. Blake -- Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com Regards, Denis Pinkas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) Multiple Signer Clarification) to Proposed Standard
to it . Now, if a phone call may allow a faster progression, I am ready to call, or here is my phone number: 00 33 1 30 80 75 24. This topic is important to me. Denis The editor's job is to make changes after consensus is built. I tried to give you (Denis) some advice on how to break up your issues and focus on what you really want. It sounds from your message to Russ like you chose not to take that path. Either way, though, the document will not change unless you build consensus to change the document. --Sam Regards, Denis Pinkas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (Cryptographic MessageSyntax (CMS) Multiple Signer Clarification) to Proposed Standard
Dear all, I have substantive comments that were initially raised during the S-MIME WG last call (December 1, 2006) and that have not been incorporated into the draft. The major issue is that the draft is proposing to state: (...) the successful validation of one signature associated with each signer is usually treated as a successful validation of the signed-data content type. and also : (...) the successful validation of one of signature from each signer ought to be treated as a successful validation of the signed-data content type. The CMS specification should not attempt to enter the area of the validation of the signed-data content type. Validity of the signed-data content type would imply validation of its semantics, whether it is signed by the right entities or not, whether it is counter-signed by the right entities or not, etc ... CMS should continue to restrict the topic of the validation of digital signatures signer by signer. Digital signature validation occurs signer by signer, independently of any other signer. Russ, one of the security area directors, responded on the list : The message is valid if one signature from each signer is valid. This illustrates the misunderstanding. We cannot say :the mesage is valid if , but we should say :the message is validly signed by one signer, if any of the signatures from that signer is valid. The next issue is that before clarifying what we should do to verify a digital signature when there are multiple signatures from the same signer, it is more important to clarify what to do to verify a single signature. The current text is not precise enough. Since it is proposed to clarify the text on validation, such a clarification should be made at the same time. I have posted to the S-MIME Mailing list proposals to improve the text. There has been no response to to this proposal. The latest strawman proposal is copied below : A recipient verifies a signature in the following way : It MUST first identify the signer's public key to be used for the verification. The signer's public key is referenced in the sid value either by an issuer distinguished name along with an issuer-specific serial number or by a subject key identifier that identifies the certificate containing the public key. If the essCertID signed attribute is present, then the public key contained in the referenced certificate shall be used. The signer's certificate may be included in the SignedData certificates field. It MUST verify that the signatureAlgorithm indicated in the SignerInfo value is compatible with the digestAlgorithm indicated in the SignerInfo value and the algorithm contained in the subjectPublicKeyInfo from the signers certificate. The following examples are provided: - if the signatureAlgorithm is sha-1WithRSAEncryption, then the digestAlgorithm must be id-sha1 and the algorithm contained in the subjectPublicKeyInfo must be rsaEncryption. - if the signatureAlgorithm is id-RSASSA-PSS, then the hashAlgorithm included in the RSASSA-PSS-params must be the same as the one indicated in the digestAlgorithm field from SignerInfo. The algorithm contained in the subjectPublicKeyInfo must either be id-RSASSA-PSS with the same parameters as those indicated in the signature algorithm or be rsaEncryption. It MUST then use the specific digestAlgorithm indicated in the SignerInfo value to compute a digest and the signatureAlgorithm indicated in the SignerInfo value with to verify the signature value, as defined in Section 5.3. In addition, it MUST verify that the strength and key size of these algorithms are conformant with the security policy, otherwise it shall discard the signature. A given signer may apply more than one signature. This may be useful in particular when some recipients are unable to process some algorithms during an algorithm migration phase. Then we could add: The signed-data content type is validly signed by one signer, if any of the digital signatures from that signer is verified as valid. Denis The IESG has received a request from the S/MIME Mail Security WG (smime) to consider the following document: - 'Cryptographic Message Syntax (CMS) Multiple Signer Clarification ' draft-ietf-smime-cms-mult-sign-02.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-sign-02.txt IESG discussion can be tracked via
Re: Last Call: 'Internet X.509 Public Key Infrastructure Warranty Certificate Extension' to Informational RFC
The IESG has received a request from the Public-Key Infrastructure (X.509)
WG to consider 'Internet X.509 Public Key Infrastructure Warranty
Certificate Extension' draft-ietf-pkix-warranty-extn-03.txt as an
Informational RFC.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
[EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2003-08-26.
I am quite surprised to see that the IESG received a request from the PKIX
chairs while a discussion still takes place on the PKIX mailing list on the
document.
The last response from the lead editor (Alice Sturgeon) is dated August 13.
She recognizes that at least some clarifications are needed.
The e-mail is duplicated below and exhibits that there is good progress but
still no consensus on the document.
At least some changes to the June version (version 3) are expected before
the document can be published.
Regards,
Denis
Note: I am back from holidays, just today (i.e. August 26 th).
===
Hello Denis,
Please see my comments inserted below, as [AS2], to distinguish from the
first set of replies to your original comments.
Alice
Alice Sturgeon
Chair, Canadian Advisory Committee - Information Technology Security
ISO/IEC JTC 1/SC 27
and
System Policy Architect Manager of Standards
SPYRUS
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Denis Pinkas
Sent: Tuesday, July 29, 2003 6:38 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-03.txt
Alice,
Please see my responses below.
Comments on warranty-extn-03.txt (June 2003)
1- On page 2. The text mentions: A relying party that has a warranty from a
CA.
Does this mean that a relying party must have a contract with the CA to get
advantage of the warranty ?
[Alice] No.
Does this mean that a relying party will get a warranty without a contract
signed with the CA ?
[Alice] Yes.
Does this extension allow to make the difference between the case of a
signed contract and the case of an unsigned contract where the guarantees
could be different?
[Alice] No. If there are any differences in the TC pertaining to a
contractual arrangement, these differences will be outside of, beyond the
scope, and not pertinent to, the warranty offered in the certificate. It
applies equally to all relying parties, whether or not a contract has been
signed.
[Denis] Then say something like: Whether or not relying parties have signed
agreements with CAs, the CA will provide Terms and Conditions for this
warranty which relates to its liability.
[AS2] Alternatively, to make the same point, it could remain implicit.
2 - The difference between the base warranty and the extended warranty is
not crystal clear.
How can a relying party know whether it can have the benefits of the base
warranty or of the extended warranty ?
If the extended warranty is present, then the relying party has the benefit
of the extended warranty. In short, if it is present, then the relying
party knows that the relying party has the benefit of the extended warranty
by its presence alone. The syntax shows that the extended warranty MAY be
present:
Warranty ::= CHOICE {
none NULL,-- No warranty provided
wDataWarrantyData } -- Explicit warranty
WarrantyData ::= SEQUENCE {
base WarrantyInfo,
extended WarrantyInfo OPTIONAL,
tcURLTermsAndConditionsURL OPTIONAL }
If the tcURL is present, a human being might understand the terms and
conditions (if he can understand the local language used), but a computer
program will not be able to do so. This means that computers cannot
understand the difference.
[Alice] The computer does not need to know what is in the TC. If the tcURL
is present, it is optionally for the benefit of the human reader. Perhaps
you could suggest some text to clarify this in the I-D if you still think it
is needed.
[Denis] Then say something like: Warranty extensions are only aimed for
human interpretation and contain data that is inappropriate for computer
based verification schemes, the warranty extension MUST NOT be an active
component in automated certification path validation.
[AS2] But this is not necessarily true. It may be that the RP (i.e., the
human) has to go to a TC document if the extended warranty is present, if
the RP wants to know what exactly is in the TC, but there should be the
option of not going to the TC. If the extended warranty is not present (as
noted in the syntax, it is optional), then there is no reason that the
extension could not be processed by the computer. Therefore, the warranty
extension is NOT only aimed for human interpretation This may be
irrelevant to the point of automated certificate path validation, because
