Re: [dss] Comments on version 7 of the core document

[Trevor Perrin <trevp@trevp.net>]

At 04:27 PM 12/4/2003 +0100, Juan Carlos Cruellas Ibarz wrote:

> >>Question: are the URI for the CMS derived from the OID as
> >>suggested in a RFC that instructs on how to derive URIs from
> >>pre-existing OIDs? If not, I think that we should follow it because
> >>in fact, the CMS HAS a UNIQUE AND PERMANENT identifier
> >>that is its OID, and the URI should be aligned with it.
> >
> >These URIs are not derived from OIDs.  They're derived according to RFC
> >2468, "A URN Namespace for IETF Documents".
> >
> >SAML also uses IETF URNs like this.  Could we stick with these URIs and
> >just add a reference to RFC 2468 in section 7?
> >
>I see.... I have got it. The funny thing is that the informational RFC  3001
>" A URN Namespace of Object Identifiers" specifically defines mechanisms
>to define urn namespaces baded on the OIDs!!, which means that somehow
>we can see different alternatives for doing things.
>Well, I do not know... one could think that we are trying to identify
>object types
>(different types of signatures) and as each one has a different OID, one
>could use
>the RFC 3001... on the other side one could think that the object is
>defined in a
>specific RFC and then follow RFC 2648 ...
>Is SAML using it to identify specific data types or specific RFC (ie
>documents)?

They're using it to identify certain protocols, by referring to the 
RFCs.  For example, if you authenticate with Kerberos, or SRP, or TLS, 
they'll use a URI for the RFC to identify that authentication method, in 
the resulting Assertion.

Since we can use RFC-based URIs to refer to XML-DSIG and PGP, and since 
these URIs are easy to dereference to get the appropriate document, I'd 
prefer to use an RFC-based URI for CMS as well.


> >>A second comment. What about to phisically separate the parts of the schema
> >>that
> >>come in the request and the parts that come in the answer? Just for
> >>avoiding any kind
> >>of confussion. The text could be something like:
> >>
> >>The <SignaturePlacement> element would appear as part of the <SignRequest>.
> >>Below
> >>follows the schema definining its contents:
> >>
> >>.....
> >>
> >>In reaction to the presence of a <SignaturePlaceement> within the request,
> >>the server
> >>MUST include the <DocumentWithSignature> element within the <SignResponse>
> >>element.
> >>Below follows....
> >>.....
> >>
> >>Or something like that.
> >
> >Do you think that's better?  I don't see a big difference either way.
> >
>I would say that in this way the fact that one goes in the request and
>that the other appears in the response would be explicit.

Agreed, I'll separate these.


> >>Second, if this is accepted, then the client must be able to instruct the
> >>server on
> >>WHAT specific update it wants...If the schema is kept unchanged, the URI
> >>will have
> >>to identify some specific signature form, ie, some signature with
> >>additional data
> >>predefined somewhere else... for instance some of the XAdES forms..
> >>I would suggest to have an additional optional element that would allow the
> >>client
> >>specify what it wants the server add to the signature by enumeration.... I
> >>am not
> >>saying that this element must be defined in the core, it can be part of a
> >>profile.
> >>So what about adding an element AnyType that would allow for that?
> >
> >Can't this be handled through the URI?
> >
> >For example, you could have different URIs like:
> >
> >urn:whatever:xades-c
> >urn:whatever:xades-x
> >urn:whatever:xades-xl
> >
>
>Your suggestion is that we should define a URI set
>identifying all the standardized XAdES forms, for instance.

I don't think we should put these URIs in the core.  Profiles could define 
these - for example, the XAdES profile could define the above.

I'm just not sure we need to add an additional extensibility point to 
<ReturnUpdatedSignatures>, since we already have the Type URI attribute.


>Then if some service discovers that its environment requires
>a form that is not standardized (a different combination of
>attributes), then the service itself can define a different URI
>for THAT specific non  standardized form... is that what
>you mean?

I think so; with the caveats above.


Trevor