You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by "George Stanchev (JIRA)" <ji...@apache.org> on 2008/02/29 18:30:51 UTC

[jira] Issue Comment Edited: (RAMPART-144) Timestamp with just create time element

    [ https://issues.apache.org/jira/browse/RAMPART-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573854#action_12573854 ] 

gstanchev edited comment on RAMPART-144 at 2/29/08 9:30 AM:
------------------------------------------------------------------

It does not. It means that the message is valid this millisecond only. If Expires < Created, then would've meant the timestamp has expired right away. Both of those are legitimate use cases, permitted by the standards. I, personally, have encountered legitimate use case for Expires < Created. If you want to be flexible, you need to allow all permitted values. 

      was (Author: gstanchev):
    It does not. It means that the message is valid this millisecond only. If Expires < Created, then would've meant the timestamp has expired right away. Both of those are legitimate use cases, permitted by the standards. I, personally, have encountered legitimate use case for created<expires. If you want to be flexible, you need to allow all permitted values. 
  
> Timestamp with just create time element
> ---------------------------------------
>
>                 Key: RAMPART-144
>                 URL: https://issues.apache.org/jira/browse/RAMPART-144
>             Project: Rampart
>          Issue Type: Bug
>          Components: rampart-core
>    Affects Versions: 1.3
>            Reporter: Narayan Singh Dhillon
>            Assignee: Ruchith Udayanga Fernando
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> If we want to just have "wsu:Created" element inside "wsu:Timestamp" then Rampart doesn't allow it. 
> WS-Security policy doesn't seem to define any policy semantics for above, but this element is optional and often not used in practical scenarios because of clock differences, but it is considered best practice to have time stamp included in XMLdSig.
> I think as Created and Expires elements are not controlled by WS-Policy, we could adopt for the flexible solutions as below:
> (1) In client side, if timestampTTL element in rampart-config is set to 0, then wsu:expires element must not be created.
> (2) On Server side, Timestamp should be validated for full, that is if Created and Expires element are present then they should be validated otherwise just created time be validated. I think this is current behaviour.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.