headers
Hal Lockhart | 1 Apr 2008 19:34

RE: [widgets-digsig] Comment on use of X.509 v3


Sorry for the delay.

I am still unclear as to what you intend to require. I do not have easy
access to [X.509v3], but I suspect that it says that a certificate MUST
have a value of 2 (indicating v3) in the version field. 

Do you expect conforming implementations which perform signature
validation to enforce this? If you do, you may run into interoperability
problems. If you do not, then the document should explicitly say so.

Hal

> -----Original Message-----
> From: Marcos Caceres [mailto:marcosscaceres <at> gmail.com]
> Sent: Monday, March 24, 2008 11:15 PM
> To: Hal Lockhart
> Cc: public-appformats <at> w3.org; member-xmlsec-maintwg-request <at> w3.org
> Subject: Re: [widgets-digsig] Comment on use of X.509 v3
> 
> HI Hal,
> 
> 
> On Fri, Mar 21, 2008 at 10:13 PM, Hal Lockhart <hlockhar <at> bea.com>
wrote:
> >
> >  The current draft of Widgets 1.0: Digital Signature says:
> >
> >  3. The digital certificate format must be [X.509v3].
> >
(Continue reading)

Permalink | Reply | 7 comments |
headers
Marcos Caceres | 2 Apr 2008 05:13
Picon
Gravatar

Re: [Widgets] confi.xml - icon element


Hi All,
During last week's teleconf [1] we discussed the proposed models for
dealing with icons. The working group reached a resolution to use the
model which was previously proposed [2] where by the widget engine
intelligently selects an icon by comparing the dimensions of the
available the display context to the dimensions of an icon. The
inclusion of a 'role' attribute was rejected on the grounds of a lack
of use cases, lack of semantics for role and the proposed
corresponding values (big, small, screenshot, etc), and because it is
not a common feature across market-leading widget engines. If vendors
wish to use 'role', then they are free to do so by including it into
their own custom namespace:

<widgets xmlns="http://www.w3.org/ns/widgets"
xmlns:ex="http://widgextension.org/" >
  <icon src="icon_ss.png" ex:role="screenshot"/>
  <icon src="icon_big.png" ex:role="big"/>
  <content src="widget.html"/>
</widgets>

The resolution the WG reached is to now allow zero or more <icon>
elements. The widget engine must derive the width and height of an
icon by inspecting the image data. The supported image formats will be
GIF87,GIF89,PNG, and JPG (SVG will be optional).

Kind regards,
Marcos

[1] http://lists.w3.org/Archives/Public/public-appformats/2008Mar/0064.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcos Caceres | 2 Apr 2008 06:32
Picon
Gravatar

[Widgets] Widget DigSig request for comments


Hi members of the Digital Signature Working Group,
The Web Application Formats Working Group is currently trying to
define a "profile" of the XML dig sig spec to use with our Widgets
Specification[1], and we were hoping to get some initial feedback. The
specification we are working on is called Widgets 1.0: Digital
Signature. The latest editor's draft can be found at [2].

The idea is simple: leverage XML DigSig to digitally sign files inside
a zip archive.

The signature scheme we are trying to define imposes a number of
restrictions on the XML-Signature Syntax and Processing Specification:

   1. All resources must be treated as digital content (data objects)
and the signature must be included in a 'signature.xml' file.
   2. RSA-SHA1 is the only supported digest method.
   3. A KeyInfo element must be present and the digital certificate
format must conform to the X509 specification (other cert formats are
not supported).
   4. The XML signature file must be encoded as [UTF-8].
   5. SignatureProperties elements are ignored by the specification,
but they may be present in a signature document.

Does that sound reasonable?

We are also wondering if we need to define our own Transform
Algorithm, as the data may be transformed from Deflate compressed data
to an uncompressed representation before being signed? For example:
(Continue reading)

Permalink | Reply | 0 comments |
headers
olli.immonen | 2 Apr 2008 09:32
Picon

RE: [widgets-digsig] Comment on use of X.509 v3


Hi,

To clarify the issue, [X.509v3] allows three version numbers, depending
on which data is included. Here is a quote from the definition
(available at http://www.itu.int/rec/T-REC-X.509-199708-S/en)

Certificate ::= SIGNED { SEQUENCE {
	version [0] Version DEFAULT v1,
	serialNumber CertificateSerialNumber,
	signature AlgorithmIdentifier,
	issuer Name,
	validity Validity,
	subject Name,
	subjectPublicKeyInfo SubjectPublicKeyInfo,
	issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,
			-- if present, version must be v2 or v3
	subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL,
		-- if present, version must be v2 or v3
	extensions [3] Extensions OPTIONAL
		-- If present, version must be v3 -- } }

Version ::= INTEGER { v1(0), v2(1), v3(2) }

RFC3280 (a profile of X.509) states a bit more exactly which version
numbers to use:

4.1.2.1  Version

   This field describes the version of the encoded certificate.  When
(Continue reading)

Permalink | Reply | 6 comments |
headers
Thomas Roessler | 2 Apr 2008 11:23
Picon
Favicon

Re: [widgets-digsig] Comment on use of X.509 v3


On 2008-04-02 10:32:39 +0300, olli.immonen <at> nokia.com wrote:

> RFC3280 (a profile of X.509) states a bit more exactly which version
> numbers to use:

...

> So, stating conformance to [X509v3] does not imply that that only v3
> would be allowed. 

Thanks for clarifying this.

A related question: Is there any reason to ask for conformance to
X509v3 directly, as opposed to asking for conformance with RFC 3280?

--

-- 
Thomas Roessler, W3C  <tlr <at> w3.org>
Permalink | Reply | 1 comment |
headers
Marcos Caceres | 2 Apr 2008 12:41
Picon
Gravatar

Re: [widgets-digsig] Comment on use of X.509 v3


Hi Thomas,
>  A related question: Is there any reason to ask for conformance to
>  X509v3 directly, as opposed to asking for conformance with RFC 3280?

To be consistent with the XML Dig Sig spec (that is the reference they use).

Kind regards,
Marcos

--

-- 
Marcos Caceres
http://datadriven.com.au
Permalink | Reply | 0 comments |
headers
Marcos Caceres | 2 Apr 2008 12:50
Picon
Gravatar

Re: [widgets-digsig] Comment on use of X.509 v3


>
>  So, stating conformance to [X509v3] does not imply that that only v3
>  would be allowed.

That was my exactly my intention when referencing [X509v3] in the spec.

Should the spec recommend one particular version of X509 certs?

Kind regards,
Marcos

--

-- 
Marcos Caceres
http://datadriven.com.au
Permalink | Reply | 0 comments |
headers
Hal Lockhart | 2 Apr 2008 22:07

RE: [widgets-digsig] Comment on use of X.509 v3


>    Implementations SHOULD be prepared to accept any version
certificate.
>    At a minimum, conforming implementations MUST recognize version 3
>    certificates.

Since this is not well understood and the document is not generally
accessible, you might want to repeat the above in your document. In
fact, I would suggest changing it to say:

Implementations MUST be prepared to accept any version certificate.

Hal

> -----Original Message-----
> From: olli.immonen <at> nokia.com [mailto:olli.immonen <at> nokia.com]
> Sent: Wednesday, April 02, 2008 3:33 AM
> To: Hal Lockhart; marcosscaceres <at> gmail.com
> Cc: public-appformats <at> w3.org; member-xmlsec-maintwg-request <at> w3.org
> Subject: RE: [widgets-digsig] Comment on use of X.509 v3
> 
> Hi,
> 
> To clarify the issue, [X.509v3] allows three version numbers,
depending
> on which data is included. Here is a quote from the definition
> (available at http://www.itu.int/rec/T-REC-X.509-199708-S/en)
> 
> Certificate ::= SIGNED { SEQUENCE {
> 	version [0] Version DEFAULT v1,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Close, Tyler J. | 3 Apr 2008 01:52
Picon
Favicon

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]


I think the XDR proposal is pretty good and is the best of the current proposals to push forward to
standardization. I hope Microsoft finds a way to make that happen.

Some responses to Jonas' comments are inline below...

Jonas Sicking wrote:
> Eric Lawrence wrote:
> > Ian--
> >
> > Thanks for sharing your opinions.  I'd like to take the
> opportunity to clarify a few points of confusion.
> >
> > <<This is blatently untrue, a number of serious security
> problems with XDR
> > have already been raised (such as the fact that it
> encourages content-type
> > sniffing
> >
> > It's possible that you overlooked some mails on the thread?
> >
> > Vis-à-vis content-type sniffing, it was plainly stated that
> Content-Type sniffing is neither recommended, nor necessary.
>
> I think you are misunderstanding the issues Ian has raised.
>
> Since XDR does not let you set the Content-Type header, the
> server is in
> fact required to sniff the content type. How else would the server
> figure out the content type of the request body?
(Continue reading)

Permalink | Reply | 32 comments |
headers
Marcos Caceres | 3 Apr 2008 02:03
Picon
Gravatar

Re: [widgets-digsig] Comment on use of X.509 v3


>  Since this is not well understood and the document is not generally
>  accessible, you might want to repeat the above in your document. In
>  fact, I would suggest changing it to say:
>
>  Implementations MUST be prepared to accept any version certificate.

The spec now reads:
"Implementations must be prepared to accept all X.509 certificates
versions identified in [X509v3] via the version field. To be clear,
the value of the version field identifies the version of an X.509
certificate in the following way:
  0 is X.509 version 1,
  1 is X.509 version 2,
  2 is X.509 version 3,
  if the version field is omitted, then treat the certificate as X.509
version 1."

Please let me know if that is clear enough.

Kind regards,
Marcos

--

-- 
Marcos Caceres
http://datadriven.com.au
Permalink | Reply | 1 comment |

Gmane