headers
Denis Pinkas | 3 Sep 2007 09:48
Picon

Re: Draft on TimeStampedData


>On Fri, Aug 31, 2007 at 12:06:00PM +0200, Tilo Kienitz wrote:
>> 
>> Adriano,
>> 
>> > After pondering on this and other remarks, I cannot help but agree 
>> > with Steve.
>> > 
>> > My original and essential goal is that of facilitating interoperability
>> > in a currently unregulated field. If we allow for several "degrees of 
>> > freedom", than interoperability will be hampered from the beginning. 
>> > So I'd better stick to RFC 3161 for now. We could include support for 
>> > RFC 4998 Evidence Records later on, at the time when they become a 
>> > widespread reality comparable to RFC 3161 TimeStampTokens (which are 
>> > widely implemented).
>> 
>> I would prefer to have both options: RFC 3161 and RFC 4998. For our
>> customers evidence records are a widespread reality already. 
>> A standardized way to put some data and their evidence record into
>> a single file would be useful.

>I strongly concur with this comment. Allowing the usage of ERS as
>well as simple timestamps would allow the TimestampedData to leverage
>all the work of RFC 4998 regarding timestamps instead of reinventing
>the wheel in the future.

RFC 4998 has already defined its own structure: ArchiveTimeStamp.
The need to expand the proposal to RFC 4998 has not been demonstrated.
Sticking to RFC 3161 will also allow better interoperability and maintain simplicity.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Santoni Adriano | 3 Sep 2007 10:41
Picon
Favicon

R: R: Draft on TimeStampedData


Let me summarize the issues discussed so far:

1) allow EvidenceRecord (RFC 4998) in addition to TimeStampToken (RFC 3161)

In principle, I have no objections as long as we do not complicate things too much and do not hamper
interoperability. 

There are at least two possible approaches to accomodate RFC 4998:

   a) explicitly provide for (one) ER in the TimeStampedData syntax, as an alternative to the SET OF TimeStampToken;
   b) do not mention any specific standard for the "evidence", but just mention RFC 3161 and RFC 4998 as two possibilities;

In any case, it must be possible for the verifying application to easily detect which of the two (or more)
kind of "evidence" has been used in the TimeStampedData envelope under examination. If we restrict the
kinds of evidence to the two above, then a extra tagging may not be necessary, as an EvidenceRecord is a
SEQUENCE, while the other choice would be a SET OF. Although unelegant, it would work. On the other hand, if
we do not want to restrict the kinds of evidence to the two above, then of course we should somehow add an
extra tagging level, because nobody knows at this time what syntax a third kind of evidence would conform to.

In any case, for the sake of interoperability, strong emphasis should be given to RFC 3161 as today this is
the most widely implemented type of evidence.

In conclusion: I agree with allowing RFC 4998 if we do that in a way that does not modify the strong emphasis on
RFC 3161 and does not hamper interoperability (which must be based on supporting RFC 3161, even though
certain applications may also support RFC 4998).

2) filename vs. URI 

Some remarked that an URI (or URI Reference) would be more versatile than a simple filename. That is
(Continue reading)

Permalink | Reply | 6 comments |
headers
Peter Sylvester | 3 Sep 2007 14:48
Picon
Picon
Favicon

Re: R: R: Draft on TimeStampedData

How is a charset of a text/plain encoded in you proposal?
Attachment (smime.p7s): application/x-pkcs7-signature, 4496 bytes
Permalink | Reply | 2 comments |
headers
Santoni Adriano | 3 Sep 2007 15:28
Picon
Favicon

R: R: R: Draft on TimeStampedData


Peter,

a text/plain object would be encoded "as is", in its native binary form -- like any other type of content, for
that matter.

I suppose the accompanying 'mimeType' field would bear a value of "text/plain" or possibly "text/plain;
charset=<charset-name>" if the charset cannot be inferred from context.

However, the 'mimeType' field in the TimeStampedData structure does not imply that the 'content' field
encloses the body of a MIME entity (if that is what you have in mind). It is intended more like a hint about
what kind of stuff can be found in the 'content' field. 

But nothing would block me if I wanted to put a full-blown MIME entity in the 'content' field, if necessary,
along with all the needed MIME headers.

I am not sure if I got your question right...

Adriano

-----Messaggio originale-----
Da: Peter Sylvester [mailto:Peter.Sylvester <at> edelweb.fr] 
Inviato: lunedì 3 settembre 2007 14.49
A: Santoni Adriano
Cc: ietf-pkix <at> imc.org
Oggetto: Re: R: R: Draft on TimeStampedData

How is a charset of a text/plain encoded in you proposal?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Sylvester | 3 Sep 2007 16:08
Picon
Picon
Favicon

Re: R: R: R: Draft on TimeStampedData

Santoni Adriano wrote:
> Peter,
>
> a text/plain object would be encoded "as is", in its native binary form -- like any other type of content,
for that matter.
>   
Of course
> I suppose the accompanying 'mimeType' field would bear a value of "text/plain" or possibly "text/plain;
charset=<charset-name>" if the charset cannot be inferred from context.
>   
Indeed, I was trying to say "how do you indicate the charset", as you say
you usethe full value of the Content-Type header field.
In other words, you could have also name="file.txt"
Thus, no extra  parameter for the file name necessary.

Or in other words, in order to enhance 4073 to meet your needs you need 
to define
one attribut containing the mime-type, i.e. the content of a mime  
Content-type header field,
or you could even define an attribute for any header field, i.e. a 
sequence of the name
and value, e.g. you would encode a sequence of

    {"Content-Type", 'text/plain; charset=ISO-8859-1;name=toto.txt"}

you may even want to add a

    {"Content-Description","This is the timestamped version of Contract 1"}
> However, the 'mimeType' field in the TimeStampedData structure does not imply that the 'content' field
encloses the body of a MIME entity (if that is what you have in mind). It is intended more like a hint about
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tilo Kienitz | 3 Sep 2007 17:28
Picon

Re: Draft on TimeStampedData


>>> I would prefer to have both options: RFC 3161 and RFC 4998. For our
>>> customers evidence records are a widespread reality already. 
>>> A standardized way to put some data and their evidence record into
>>> a single file would be useful.
> 
>>I strongly concur with this comment. Allowing the usage of ERS as
>>well as simple timestamps would allow the TimestampedData to leverage
>>all the work of RFC 4998 regarding timestamps instead of reinventing
>>the wheel in the future.
> 
> RFC 4998 has already defined its own structure: ArchiveTimeStamp.

An ArchiveTimeStamp does not contain a document. It only contains
hashes of documents.

> The need to expand the proposal to RFC 4998 has not been demonstrated.

If someone wants to keep a document and its EvidenceRecord together 
in a single file, then the proposal will help him. 

Tilo
Permalink | Reply | 34 comments |
headers
Stefan Santesson | 5 Sep 2007 15:29
Picon
Favicon

RE: CRL Processing Algorithm


Mauricio,

I think the following current text from section 6.3 is sufficient:

   This algorithm assumes that all of the needed CRLs are available in a
   local cache.  Further, if the next update time of a CRL has passed,
   the algorithm assumes a mechanism to fetch a current CRL and place it
   in the local CRL cache.

This text is also present in rfc3280bis.

Matt Cooper wrote:
> An example of this behavior is Microsoft Smart Card Logon (SCL).  Once
> configured on the domain, users can use a smart card to authenticate to
> the Domain Controller and logon to their workstation.  Problem here is
> that if for some reason the CRL for the user certificate is unavailable
> at the point nextUpdate passes, the user can not log on because the
> Domain Controller will reject it.  Now imagine that the CRL is
> unavailable because of a network problem and an entire corporation
> grinds to a halt when no one can log on in the morning.  That behavior
> is clearly unacceptable.  Microsoft recognized this was a problem and
> added a "grace period" setting that allows a Domain Controller to
> utilize CRLs for a fixed interval beyond the nextUpdate.

More so, since most implementations treat nextUpdate also as an expiration field (since there is no other
date to indicate when the CRL is too old to be used), Microsoft CA also adds another optional non-critical
CRL extension "Next Publish". This in practice works as an optional extra nextUpdate field to specify
when a new CRL is likely to be available even before the NextUpdate time. This provides a natural grace
period between NextPublish and NextUpdate for those understanding the extension.
(Continue reading)

Permalink | Reply | 0 comments |
headers
George Michaelson | 6 Sep 2007 08:46
X-Face
Favicon

request for WG to adopt draft-chadwick-webdav-00.txt as a work item


I am very interested in the construction of a systematic framework for
webdav based publication protocols to be used to publish into
repositories. Other WG areas of work are considering adoption of
certificate based models which require large, distributed repositories
to be maintained, and will imply a repository provisioning protocol.

I therefore wish to propose the WG adopt draft-chadwick-webdav-00.txt as a work item.

I would also like to ask that the document be slightly modified, to
present two distinct parts in the proposal

1) that part which documents use of WEBDAV as a repository publication
   protocol and the use of a REST model.

2) that part which discusses naming of the repository objects in the
   repository, eg for use in the SIA and AIA fields, and the related
   REST model name mapping.

The reason I ask that it be re-worked in this way is that there are
other models of repository naming architecture which do not have
'deep' RDN name structure in the certificate Subject name, and are less
ameanable to a deterministic mapping as Dave has proposed. If the
document is re-worked slightly to make it plain that this is only one
of many repository naming models, it will be easier for related work to
cite this document in reference to part 1) use of WEBDAV and to draw up
a distinct repository name mapping function reflecting part 2) in
spirit.

I have some very minor concerns with stipulating the correct TLS
(Continue reading)

Permalink | Reply | 10 comments |
headers
Stefan Santesson | 6 Sep 2007 12:12
Picon
Favicon

RE: request for WG to adopt draft-chadwick-webdav-00.txt as a work item


Thanks for bringing this up George.

As for all solutions to problems where there already exist other solutions to the same problems, it is
important to determine why we need another solution to the same problem.

There is a value to have a limited standardized set of ways to do things as it makes interoperability easier.
Sometimes we choose to offer multiple solutions anyway, mostly to enable re-use of existing infrastructures.

I would like to hear more about why it is important to add this to the menu of repository solutions and
revocation mechanisms.

My personal concern about the presented approach is that it changes the trust mechanism for certificate
revocation from signed objects (CRLs and OCSP responses) to trust in a repository infrastructure. That
is, if I get a certificate in return from an expected location it is supposed to be valid. Yet, when revoked a
1 post CRL is examined making revocation CRL based. I don't think this fits with the model of CRL processing
described in section 6.3 of RFC 3280.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-
> pkix <at> mail.imc.org] On Behalf Of George Michaelson
> Sent: den 6 september 2007 08:47
> To: ietf-pkix <at> imc.org
> Subject: request for WG to adopt draft-chadwick-webdav-00.txt as a work
> item
>
(Continue reading)

Permalink | Reply | 9 comments |
headers
George Michaelson | 6 Sep 2007 12:37
X-Face
Favicon

Re: request for WG to adopt draft-chadwick-webdav-00.txt as a work item


On Thu, 6 Sep 2007 11:12:05 +0100
Stefan Santesson <stefans <at> microsoft.com> wrote:

> 
> Thanks for bringing this up George.
> 
> As for all solutions to problems where there already exist other
> solutions to the same problems, it is important to determine why we
> need another solution to the same problem.
> 

Yes. I certainly agree that 'just because we can' is not a good basis
for deciding to do things. However, there is something about REST which
I observe is being used by a wide community of people as infrastructure
technology, to build systems. Equally, webdav has become something
which is trivially available. And, it is remarkably easy to deploy on
the web server-side.

So I see a useful convergence of desire (wide uptake of certificate
backed processes, which require access to repositories) and reality
(technologies which are easy to deploy, and can be used to bootstrap
and maintain certificate repositories). But it reflects my world view.
I haven't found widespread uptake of the more traditional mechanisms
that have been available to date. Like many others, I don't see
aggressive use of the various existing CRL/OCSP check methods. I do
think that webdav, being more generally deployed and useful, may be
enabling technology for certificate use.

> There is a value to have a limited standardized set of ways to do
(Continue reading)

Permalink | Reply | 8 comments |

Gmane