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

RE: I-D ACTION:draft-ietf-smime-rfc2634-update-00.txt

This is not a comment on the proposed draft text, but rather a question as to
whether the issue discussed below should be addressed by adding another
"enhanced service" to ESS or rather to consider a separate draft.

The inclination is to keep it separate to avoid delaying ESS-bis, but it MAY
logically fit within ESS...

The response to this e-mail could be:

1. Lets add a section to ESS to address this issue.
2. Issue sounds interesting but it should be proposed as a separate draft and
we'll look at it.
3. This can already be done with "XYZ".
4. Not interested (silence).

In any event, it provides an opportunity to breach the issue to the list and
invite opinions!

What is all this about?

It is argued that there is a need for a scheme to permit the inclusion of "proof
of signing-certificate validation" in signed messages (and potentially in signed
receipts).  ESS section 5 discusses a related issue.

Traditional signed messaging using CMS and MSG is based on the originator
appending a signature to a message which is subsequently checked by the message
receiver(s), with receivers checking the validity (e.g. revocation status) of
the corresponding public key certificate.  This method has problems (detailed
below) which could be mitigated if there was a way to force the certificate (and
certificate use) validation to occur at signing time (or close to signing time).

The traditional method has shortcomings in situations where signature validation
occurs some time after signature creation, as is common in S/MIME environments
where signed messages, including archived messages, may be checked months and
possibly years later.  If a key compromise and revocation were to occur in the
meantime, or the certificate were to expire, the signature will be incorrectly
judged as invalid (or incapable of being verified). (Some implementations try to
cache old crls to permit old messages to be validated, but this opens security
holes.)

It is also a concern when attempting to use this method for non-repudiation;
since the subsequent compromise of the key (accidentally or otherwise) permits
the originator to retroactively refute its creation.  (And non-repudiation is
not supported past certificate expiry.) 

A Time Stamp Server may be used to establish that the message existed prior to a
certain time so that subsequent key compromise (or certificate expiry) will not
invalidate the signature.  However, this requires adjustment to the way in which
the messages are handled (e.g. copied to time stamp servers) and these services
normally do not fully understand originator security policies and cannot fully
validate "correct use" of the certificate (as will be discussed next). 

Another issue arises if enterprises want to enforce how signatures are applied
using their certificates. For example the enterprises may wish to enforce the
X.509 privateKeyUsagePeriod attribute.  Enforcement of the "not Before" time is
not possible with current approaches, and enforcement of "not After" suffers
from the same limitations discussed above.  That is, the signature may have been
applied at a valid time, but the subsequent check by the receiver may occur
after signing key usage expiry, producing an erroneous negative result (and
realizing that the "signing time" in the message cannot be trusted since it is
only protected by the signature being verified).

Uncommon or unique-to-the-originating-enterprise signing-key usage restrictions
may also not be capable of being enforced by receivers (or time stamp servers)
since only the originating enterprise may understand their relevance.

Some environments may further require the inclusion of fixed "boilerplate" or
dynamically generated text statements limiting liability, or the inclusion of
attribute certificates.  While such statements may be included in certificates,
or the security policies associated with certificates, some enterprises may need
to use dynamic approaches which can be applied when the signature is applied.

For example, authorization to commit the organization (e.g. in a purchase order)
may be dynamically altered based on the date or temporarily delegated to
specific identities (to support "acting" authorities, to designate current
signing authority -"this signature is valid only for purchases up to $10,000"-,
etc).

Finally, in automated applications, for example SCADA (Supervisory Control and
Data Acquisition) and telecontrol applications, the relaxation of receiver
revocation checking requirements will permit the deployment of receivers (e.g.
actuators) with limited processing and on-line access capabilities. For example,
a programmable controller creating a command for a remote actuator could be
required to obtain and include the "proof" signerInfo obtained from a local
security server.  By using short certificate periods in the server and trusted
clocks in the server and actuator, an adequately secure (potentially
unidirectional simplex) command/control link might be established.

Proposal:

It is initially proposed to only define the "proof of signing certificate
validation" signerInfo structure.  The specification of how the originator, or
any intermediate element, obtains this signerInfo from a "security server" could
be left open since this is not required for interoperability between the
originator and receiver.  This operation will occur within the originating
enterprise and thus it MAY be implemented in a proprietary manner.  Depending
upon interest it might be advantageous to expose this interface and identify a
protocol however.

The "proof of certificate validation" SignerInfo itself will rely on the use of
a public certificate and so one might argue that this only replaces one
validation with another.  However, it is argued that the "proof of certificate
validation" SignerInfo is created by a device high in the organization's trust
hierarchy which can have better key protection, potentially shorter certificate
periods, and implement other measures to reduced the probability of compromise,
and thus the need for automated certificate validation may be avoided (e.g.
replaced by manual means).

If there is interest on the list, Peter Gutmann and I will put together a draft.

HOWEVER, if Jim Schaad and the list were to prefer it be included in the ESS
revision we would happily turn it over!

Tony

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

Tony,

3. This is already done with RFC 3126, "Electronic Signature
     Formats for long term electronic signatures".

RFC 3126 does not support the exact solution you propose, but provides a 
solution to the problem you want to solve.

Denis

> This is not a comment on the proposed draft text, but rather a question as to
> whether the issue discussed below should be addressed by adding another
> "enhanced service" to ESS or rather to consider a separate draft.
> 
> The inclination is to keep it separate to avoid delaying ESS-bis, but it MAY
> logically fit within ESS...
> 
> The response to this e-mail could be:
> 
> 1. Lets add a section to ESS to address this issue.
> 2. Issue sounds interesting but it should be proposed as a separate draft and
> we'll look at it.
> 3. This can already be done with "XYZ".
> 4. Not interested (silence).
> 
> 
> In any event, it provides an opportunity to breach the issue to the list and
> invite opinions!
> 
> What is all this about?
> 
> It is argued that there is a need for a scheme to permit the inclusion of "proof
> of signing-certificate validation" in signed messages (and potentially in signed
> receipts).  ESS section 5 discusses a related issue.
> 
> Traditional signed messaging using CMS and MSG is based on the originator
> appending a signature to a message which is subsequently checked by the message
> receiver(s), with receivers checking the validity (e.g. revocation status) of
> the corresponding public key certificate.  This method has problems (detailed
> below) which could be mitigated if there was a way to force the certificate (and
> certificate use) validation to occur at signing time (or close to signing time).
> 
> The traditional method has shortcomings in situations where signature validation
> occurs some time after signature creation, as is common in S/MIME environments
> where signed messages, including archived messages, may be checked months and
> possibly years later.  If a key compromise and revocation were to occur in the
> meantime, or the certificate were to expire, the signature will be incorrectly
> judged as invalid (or incapable of being verified). (Some implementations try to
> cache old crls to permit old messages to be validated, but this opens security
> holes.)
> 
> It is also a concern when attempting to use this method for non-repudiation;
> since the subsequent compromise of the key (accidentally or otherwise) permits
> the originator to retroactively refute its creation.  (And non-repudiation is
> not supported past certificate expiry.) 
> 
> A Time Stamp Server may be used to establish that the message existed prior to a
> certain time so that subsequent key compromise (or certificate expiry) will not
> invalidate the signature.  However, this requires adjustment to the way in which
> the messages are handled (e.g. copied to time stamp servers) and these services
> normally do not fully understand originator security policies and cannot fully
> validate "correct use" of the certificate (as will be discussed next). 
> 
> Another issue arises if enterprises want to enforce how signatures are applied
> using their certificates. For example the enterprises may wish to enforce the
> X.509 privateKeyUsagePeriod attribute.  Enforcement of the "not Before" time is
> not possible with current approaches, and enforcement of "not After" suffers
> from the same limitations discussed above.  That is, the signature may have been
> applied at a valid time, but the subsequent check by the receiver may occur
> after signing key usage expiry, producing an erroneous negative result (and
> realizing that the "signing time" in the message cannot be trusted since it is
> only protected by the signature being verified).
> 
> Uncommon or unique-to-the-originating-enterprise signing-key usage restrictions
> may also not be capable of being enforced by receivers (or time stamp servers)
> since only the originating enterprise may understand their relevance.
> 
> Some environments may further require the inclusion of fixed "boilerplate" or
> dynamically generated text statements limiting liability, or the inclusion of
> attribute certificates.  While such statements may be included in certificates,
> or the security policies associated with certificates, some enterprises may need
> to use dynamic approaches which can be applied when the signature is applied.
> 
> For example, authorization to commit the organization (e.g. in a purchase order)
> may be dynamically altered based on the date or temporarily delegated to
> specific identities (to support "acting" authorities, to designate current
> signing authority -"this signature is valid only for purchases up to $10,000"-,
> etc).
> 
> Finally, in automated applications, for example SCADA (Supervisory Control and
> Data Acquisition) and telecontrol applications, the relaxation of receiver
> revocation checking requirements will permit the deployment of receivers (e.g.
> actuators) with limited processing and on-line access capabilities. For example,
> a programmable controller creating a command for a remote actuator could be
> required to obtain and include the "proof" signerInfo obtained from a local
> security server.  By using short certificate periods in the server and trusted
> clocks in the server and actuator, an adequately secure (potentially
> unidirectional simplex) command/control link might be established.
> 
> Proposal:
> 
> It is initially proposed to only define the "proof of signing certificate
> validation" signerInfo structure.  The specification of how the originator, or
> any intermediate element, obtains this signerInfo from a "security server" could
> be left open since this is not required for interoperability between the
> originator and receiver.  This operation will occur within the originating
> enterprise and thus it MAY be implemented in a proprietary manner.  Depending
> upon interest it might be advantageous to expose this interface and identify a
> protocol however.
> 
> The "proof of certificate validation" SignerInfo itself will rely on the use of
> a public certificate and so one might argue that this only replaces one
> validation with another.  However, it is argued that the "proof of certificate
> validation" SignerInfo is created by a device high in the organization's trust
> hierarchy which can have better key protection, potentially shorter certificate
> periods, and implement other measures to reduced the probability of compromise,
> and thus the need for automated certificate validation may be avoided (e.g.
> replaced by manual means).
> 
> 
> If there is interest on the list, Peter Gutmann and I will put together a draft.
> 
> HOWEVER, if Jim Schaad and the list were to prefer it be included in the ESS
> revision we would happily turn it over!
> 
> 
> Tony
> 
> 

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

> > This is not a comment on the proposed draft text, but rather a question as to
> > whether the issue discussed below should be addressed by adding another
> > "enhanced service" to ESS or rather to consider a separate draft.
> > 
> > The inclination is to keep it separate to avoid delaying ESS-bis, but it MAY
> > logically fit within ESS...
> > 
> > The response to this e-mail could be:
> > 
> > 1. Lets add a section to ESS to address this issue.
> > 2. Issue sounds interesting but it should be proposed as a separate draft and
> > we'll look at it.
> > 3. This can already be done with "XYZ".
> > 4. Not interested (silence).
> > 

the ad-hoc techniques od RFC 3126 adding time stamps are one point.

As far as I remember there is also the possibility in PKCS9 to add a 'contenttype'
structure as an attribute of whatever attesttion a 'signature validation' service
(e.g. RFC 3029) can produce. 

Also, The topic of validation of signed documents seems to be part of
the ltans group (notarisation). A binding of to a concrete
field in CMS/ESS signedData as an attribute or so seems useful to me
but to do this as generic as possible.

What may fit logically into ESS seems to me is an 'extended rule for validation'
of such structures, similar to the rule to validate ESSSigningCertificate.

RE: I-D ACTION:draft-ietf-smime-rfc2634-update-00.txt

Denis:

I did look at 3126 and indeed hope that the solution would be as close a subset
(profile) of that as possible.

3126 has many capabilities, but was hoping for a simple way for originators (or
originating domain gateways) to add information bound to the message instance
which would reduce the load on the ultimate receivers - and especially receivers
operating in foreign domains who do not want to understand certificate
restrictions imposed within the originating domain.  Also reducing receiver load
is essential for telecontrol and SCADA where the actuators are simple and
potentially on the end of restrictive communications links.

I would not expect this to replace 3126 for more complex applications or where
formal legal requirements must be met.

An ideal solution could be a subset profile of 3126, potentially adding (as
necessary) optional attributes.  Also simplifications are possible since the
"proof..." signerInfo is always constructed within the originating domain (so
cross-certification, cert chaining, third party servers (including time stamp
servers, arbiters, ...), etc. are not required). 

Denis, I wonder if you could suggest a profile of 3126 which could be used?  If
we can do this with a profile alone without anything new this would make
everything easier.  I was hoping all we needed was an appropriate signerInfo
structure definition along with non-normative words describing how it is used.

Tony

| -----Original Message-----
| From: owner-ietf-smime <at> mail.imc.org 
| [mailto:owner-ietf-smime <at> mail.imc.org] On Behalf Of Denis Pinkas
| Sent: December 10, 2004 8:47 AM
| To: Tony Capel
| Cc: ietf-smime <at> imc.org; Peter Gutmann
| Subject: Re: I-D ACTION:draft-ietf-smime-rfc2634-update-00.txt
| 
| 
| 
| Tony,
| 
| 3. This is already done with RFC 3126, "Electronic Signature
|      Formats for long term electronic signatures".
| 
| RFC 3126 does not support the exact solution you propose, but 
| provides a 
| solution to the problem you want to solve.
| 
| Denis
| 
| 
| > This is not a comment on the proposed draft text, but rather a 
| > question as to whether the issue discussed below should be 
| addressed 
| > by adding another "enhanced service" to ESS or rather to consider a 
| > separate draft.
| > 
| > The inclination is to keep it separate to avoid delaying 
| ESS-bis, but 
| > it MAY logically fit within ESS...
| > 
| > The response to this e-mail could be:
| > 
| > 1. Lets add a section to ESS to address this issue.
| > 2. Issue sounds interesting but it should be proposed as a separate 
| > draft and we'll look at it. 3. This can already be done with "XYZ".
| > 4. Not interested (silence).
| > 
| > 
| > In any event, it provides an opportunity to breach the issue to the 
| > list and invite opinions!
| > 
| > What is all this about?
| > 
| > It is argued that there is a need for a scheme to permit 
| the inclusion 
| > of "proof of signing-certificate validation" in signed 
| messages (and 
| > potentially in signed receipts).  ESS section 5 discusses a related 
| > issue.
| > 
| > Traditional signed messaging using CMS and MSG is based on the 
| > originator appending a signature to a message which is subsequently 
| > checked by the message receiver(s), with receivers checking the 
| > validity (e.g. revocation status) of the corresponding public key 
| > certificate.  This method has problems (detailed
| > below) which could be mitigated if there was a way to force 
| the certificate (and
| > certificate use) validation to occur at signing time (or 
| close to signing time).
| > 
| > The traditional method has shortcomings in situations where 
| signature 
| > validation occurs some time after signature creation, as is 
| common in 
| > S/MIME environments where signed messages, including archived 
| > messages, may be checked months and possibly years later.  If a key 
| > compromise and revocation were to occur in the meantime, or the 
| > certificate were to expire, the signature will be 
| incorrectly judged 
| > as invalid (or incapable of being verified). (Some 
| implementations try 
| > to cache old crls to permit old messages to be validated, 
| but this opens security
| > holes.)
| > 
| > It is also a concern when attempting to use this method for 
| > non-repudiation; since the subsequent compromise of the key 
| > (accidentally or otherwise) permits the originator to retroactively 
| > refute its creation.  (And non-repudiation is not supported past 
| > certificate expiry.)
| > 
| > A Time Stamp Server may be used to establish that the 
| message existed 
| > prior to a certain time so that subsequent key compromise (or 
| > certificate expiry) will not invalidate the signature.  
| However, this 
| > requires adjustment to the way in which the messages are 
| handled (e.g. 
| > copied to time stamp servers) and these services normally 
| do not fully 
| > understand originator security policies and cannot fully validate 
| > "correct use" of the certificate (as will be discussed next).
| > 
| > Another issue arises if enterprises want to enforce how 
| signatures are 
| > applied using their certificates. For example the 
| enterprises may wish 
| > to enforce the X.509 privateKeyUsagePeriod attribute.  
| Enforcement of 
| > the "not Before" time is not possible with current approaches, and 
| > enforcement of "not After" suffers from the same 
| limitations discussed 
| > above.  That is, the signature may have been applied at a 
| valid time, 
| > but the subsequent check by the receiver may occur after 
| signing key 
| > usage expiry, producing an erroneous negative result (and realizing 
| > that the "signing time" in the message cannot be trusted 
| since it is 
| > only protected by the signature being verified).
| > 
| > Uncommon or unique-to-the-originating-enterprise signing-key usage 
| > restrictions may also not be capable of being enforced by receivers 
| > (or time stamp servers) since only the originating enterprise may 
| > understand their relevance.
| > 
| > Some environments may further require the inclusion of fixed 
| > "boilerplate" or dynamically generated text statements limiting 
| > liability, or the inclusion of attribute certificates.  While such 
| > statements may be included in certificates, or the security 
| policies 
| > associated with certificates, some enterprises may need to 
| use dynamic 
| > approaches which can be applied when the signature is applied.
| > 
| > For example, authorization to commit the organization (e.g. in a 
| > purchase order) may be dynamically altered based on the date or 
| > temporarily delegated to specific identities (to support "acting" 
| > authorities, to designate current signing authority -"this 
| signature 
| > is valid only for purchases up to $10,000"-, etc).
| > 
| > Finally, in automated applications, for example SCADA (Supervisory 
| > Control and Data Acquisition) and telecontrol applications, the 
| > relaxation of receiver revocation checking requirements will permit 
| > the deployment of receivers (e.g.
| > actuators) with limited processing and on-line access 
| capabilities. For example,
| > a programmable controller creating a command for a remote 
| actuator could be
| > required to obtain and include the "proof" signerInfo 
| obtained from a local
| > security server.  By using short certificate periods in the 
| server and trusted
| > clocks in the server and actuator, an adequately secure (potentially
| > unidirectional simplex) command/control link might be established.
| > 
| > Proposal:
| > 
| > It is initially proposed to only define the "proof of signing 
| > certificate validation" signerInfo structure.  The specification of 
| > how the originator, or any intermediate element, obtains this 
| > signerInfo from a "security server" could be left open 
| since this is 
| > not required for interoperability between the originator 
| and receiver.  
| > This operation will occur within the originating enterprise 
| and thus 
| > it MAY be implemented in a proprietary manner.  Depending upon 
| > interest it might be advantageous to expose this interface and 
| > identify a protocol however.
| > 
| > The "proof of certificate validation" SignerInfo itself 
| will rely on 
| > the use of a public certificate and so one might argue that 
| this only 
| > replaces one validation with another.  However, it is 
| argued that the 
| > "proof of certificate validation" SignerInfo is created by a device 
| > high in the organization's trust hierarchy which can have 
| better key 
| > protection, potentially shorter certificate periods, and implement 
| > other measures to reduced the probability of compromise, 
| and thus the 
| > need for automated certificate validation may be avoided (e.g. 
| > replaced by manual means).
| > 
| > 
| > If there is interest on the list, Peter Gutmann and I will put 
| > together a draft.
| > 
| > HOWEVER, if Jim Schaad and the list were to prefer it be 
| included in 
| > the ESS revision we would happily turn it over!
| > 
| > 
| > Tony
| > 
| > 
| 
| 

I-D ACTION:draft-ietf-smime-certcapa-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Certificate extension for S/MIME Capabilities
	Author(s)	: S. Santesson
	Filename	: draft-ietf-smime-certcapa-02.txt
	Pages		: 5
	Date		: 2004-12-13
	
This document defines a certificate extension for inclusion of S/MIME
   capabilities in public key certificates defined by RFC 3280.

   S/MIME Capabilities provides an optional method to communicate
   cryptographic capabilities of the certified subject as a complement
   to use of the S/MIME Capabilities signed attribute in S/MIME messages
   according to RFC 3851.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-certcapa-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-certcapa-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-certcapa-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt

Stefan,

A couple of small comments on the draft, although I believe that it could go
to last call in its current state.

1.  In section 2 you have the statement 'Algorithms should be ordered by
preference.'  As I general rule I attempt to avoid the use of must, should
and may when writing documents to avoid confusion with MUST, SHOULD and MAY
(did he just forget to capatilize it?).  A better statement might be
'Algorithms are expected to be be ordered by preference'.

2.  I would like to see the addition of a paragraph describing the types of
capabilities that are expected to be listed.  It seems obious that bulk
encryption algorithms are listed as, potentially, are key encryption
algorithms (consider RSA-OAEP as an example).  However it is not clear about
some of the other potential capabililties.  What about signature and hash
algorithms?  What about MAC algorithms?  What about S/MIME specifics such as
id-cap-preferBinaryInside?

3.  RFC 2199 is a reference, but the text refering to it is absent.

4.  RFC 3280 is referenced only from the abstract.  Duplicate text should be
placed in section 1.

jim

RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt

Thanks Jim,

I agree on 1 3 and 4 to be fixed.

I'm not so sure with 2. I think any such recommendations should be
handled in RFC 3851 where the S/MIME Capabilities attribute is defined.
No use of this extension in certificate should differ in any way from
its use as signed attribute in S/MIME messages.

I think that it would be confusing if we started to actually
specify/recommend the attribute content in 2 separate RFCs.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Jim Schaad [mailto:ietf <at> augustcellars.com]
> Sent: den 13 december 2004 15:01
> To: Stefan Santesson
> Cc: ietf-smime <at> imc.org
> Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
> 
> Stefan,
> 
> A couple of small comments on the draft, although I believe that it
could
> go
> to last call in its current state.
> 
> 1.  In section 2 you have the statement 'Algorithms should be ordered
by
> preference.'  As I general rule I attempt to avoid the use of must,
should
> and may when writing documents to avoid confusion with MUST, SHOULD
and
> MAY
> (did he just forget to capatilize it?).  A better statement might be
> 'Algorithms are expected to be be ordered by preference'.
> 
> 2.  I would like to see the addition of a paragraph describing the
types
> of
> capabilities that are expected to be listed.  It seems obious that
bulk
> encryption algorithms are listed as, potentially, are key encryption
> algorithms (consider RSA-OAEP as an example).  However it is not clear
> about
> some of the other potential capabililties.  What about signature and
hash
> algorithms?  What about MAC algorithms?  What about S/MIME specifics
such
> as
> id-cap-preferBinaryInside?
> 
> 3.  RFC 2199 is a reference, but the text refering to it is absent.
> 
> 4.  RFC 3280 is referenced only from the abstract.  Duplicate text
should
> be
> placed in section 1.
> 
> 
> jim
> 

RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt

Stefan,

I believe that I could easily justify differences in behaviors here.
However I think you need to put in some text saying that there is no
difference as to what is included and a small justification for this.

jim 

> -----Original Message-----
> From: Stefan Santesson [mailto:stefans <at> microsoft.com] 
> Sent: Monday, December 13, 2004 3:48 PM
> To: ietf <at> augustcellars.com
> Cc: ietf-smime <at> imc.org
> Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
> 
> Thanks Jim,
> 
> I agree on 1 3 and 4 to be fixed.
> 
> I'm not so sure with 2. I think any such recommendations 
> should be handled in RFC 3851 where the S/MIME Capabilities 
> attribute is defined.
> No use of this extension in certificate should differ in any 
> way from its use as signed attribute in S/MIME messages.
> 
> I think that it would be confusing if we started to actually 
> specify/recommend the attribute content in 2 separate RFCs.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> > -----Original Message-----
> > From: Jim Schaad [mailto:ietf <at> augustcellars.com]
> > Sent: den 13 december 2004 15:01
> > To: Stefan Santesson
> > Cc: ietf-smime <at> imc.org
> > Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
> > 
> > Stefan,
> > 
> > A couple of small comments on the draft, although I believe that it
> could
> > go
> > to last call in its current state.
> > 
> > 1.  In section 2 you have the statement 'Algorithms should 
> be ordered
> by
> > preference.'  As I general rule I attempt to avoid the use of must,
> should
> > and may when writing documents to avoid confusion with MUST, SHOULD
> and
> > MAY
> > (did he just forget to capatilize it?).  A better statement 
> might be 
> > 'Algorithms are expected to be be ordered by preference'.
> > 
> > 2.  I would like to see the addition of a paragraph describing the
> types
> > of
> > capabilities that are expected to be listed.  It seems obious that
> bulk
> > encryption algorithms are listed as, potentially, are key 
> encryption 
> > algorithms (consider RSA-OAEP as an example).  However it 
> is not clear 
> > about some of the other potential capabililties.  What 
> about signature 
> > and
> hash
> > algorithms?  What about MAC algorithms?  What about S/MIME specifics
> such
> > as
> > id-cap-preferBinaryInside?
> > 
> > 3.  RFC 2199 is a reference, but the text refering to it is absent.
> > 
> > 4.  RFC 3280 is referenced only from the abstract.  Duplicate text
> should
> > be
> > placed in section 1.
> > 
> > 
> > jim
> > 
> 
> 
> 

RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt

Thanks Jim,

I can't think of any justifications for differences myself so it will be
hard for me to add any to the spec.

If you still think we should specify differences, could you share your
justifications for them for consideration? 

Otherwise I will be happy to just add text stating that there are no
differences.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

> -----Original Message-----
> From: Jim Schaad [mailto:ietf <at> augustcellars.com]
> Sent: den 13 december 2004 17:23
> To: Stefan Santesson
> Cc: ietf-smime <at> imc.org
> Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
> 
> Stefan,
> 
> I believe that I could easily justify differences in behaviors here.
> However I think you need to put in some text saying that there is no
> difference as to what is included and a small justification for this.
> 
> jim
> 
> > -----Original Message-----
> > From: Stefan Santesson [mailto:stefans <at> microsoft.com]
> > Sent: Monday, December 13, 2004 3:48 PM
> > To: ietf <at> augustcellars.com
> > Cc: ietf-smime <at> imc.org
> > Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
> >
> > Thanks Jim,
> >
> > I agree on 1 3 and 4 to be fixed.
> >
> > I'm not so sure with 2. I think any such recommendations
> > should be handled in RFC 3851 where the S/MIME Capabilities
> > attribute is defined.
> > No use of this extension in certificate should differ in any
> > way from its use as signed attribute in S/MIME messages.
> >
> > I think that it would be confusing if we started to actually
> > specify/recommend the attribute content in 2 separate RFCs.
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> > > -----Original Message-----
> > > From: Jim Schaad [mailto:ietf <at> augustcellars.com]
> > > Sent: den 13 december 2004 15:01
> > > To: Stefan Santesson
> > > Cc: ietf-smime <at> imc.org
> > > Subject: RE: I-D ACTION:draft-ietf-smime-certcapa-02.txt
> > >
> > > Stefan,
> > >
> > > A couple of small comments on the draft, although I believe that
it
> > could
> > > go
> > > to last call in its current state.
> > >
> > > 1.  In section 2 you have the statement 'Algorithms should
> > be ordered
> > by
> > > preference.'  As I general rule I attempt to avoid the use of
must,
> > should
> > > and may when writing documents to avoid confusion with MUST,
SHOULD
> > and
> > > MAY
> > > (did he just forget to capatilize it?).  A better statement
> > might be
> > > 'Algorithms are expected to be be ordered by preference'.
> > >
> > > 2.  I would like to see the addition of a paragraph describing the
> > types
> > > of
> > > capabilities that are expected to be listed.  It seems obious that
> > bulk
> > > encryption algorithms are listed as, potentially, are key
> > encryption
> > > algorithms (consider RSA-OAEP as an example).  However it
> > is not clear
> > > about some of the other potential capabililties.  What
> > about signature
> > > and
> > hash
> > > algorithms?  What about MAC algorithms?  What about S/MIME
specifics
> > such
> > > as
> > > id-cap-preferBinaryInside?
> > >
> > > 3.  RFC 2199 is a reference, but the text refering to it is
absent.
> > >
> > > 4.  RFC 3280 is referenced only from the abstract.  Duplicate text
> > should
> > > be
> > > placed in section 1.
> > >
> > >
> > > jim
> > >
> >
> >
> >
>