[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: [dss-x] Comments to the individual report profile
Hallo Juan-Carlos,
here is some feedback w.r.t. your comments.
> Below follow those ones that I would like to talk about at
> the next call:
>
> 1. More conformance levels given the huge amount of elements
> that would
> require compliance with the current advanced level.
OK. We now have 3 levels:
- Basic
- Comprehensive
- Convenient
>
> 2. Making CertificatePathValidity optional in a number of
> elements where
> this is mandatory, as we could be repeating information.
I would prefer to leave it mandatory to indicate in each case on which
certificate the corresponding signature is based. But if the same
certificate appears multiple times the PathValidityDetail-element
may be dropped. The description now is as follows:
"<PathValidityDetail> [Optional]
Contains detailed results of the certificate path validation, if the
element <ReportDetailLevel> in the report options (see Section 3.1) was
set to urn:oasis:names:tc:dss:1.0:
profiles:verificationreport:reportdetail:allDetails and the detailed
validity information has not been included elsewhere in the verification
report. "
>
> 3. DetailType semantics redefinition. Changing the namespace for this
> new element?
OK. Instead of the DetailType we now have the specific
VerificationResultType (see Section 3.4)
>
> 4. Starting description of optional elements by "This element MAY
> [contain / indicate]..."
Yes, I tried to change this where appropriate.
>
> 5. Comment on line 277.
Which line???
> Regards
>
> Juan Carlos.
>
> PD: Ezer, will try to go through the visible signature profile during
> this weekend....
>
> ---->
> General comment: after re-reading the document and thinking about, I
> would say that the two conformance level are still not
> enough. I mean,
> that the amount of elements that an application conformant to the
> advanced level should be able to process is very big. I would
> suggest to
> think if it would be possible to have more granularity in the
> conformance levels. Something like this:
>
> 1. Level 1: individual report for each signature. Only saying
> valid/invalid/incomplete. Only Optional outputs appearing the Core.
> 2. Level 2: Level 1 plus references to the validation
> material managed
> for the verification (i.e.: identifiers of certificates, crls, ocsps,
> times-tamp tokens, etc).
> 3. Level 3: Level 2 plus values of the validation material
> managed for
> the verification.
> 4. Level 4: Level 3 plus the XML version of the different
> validation
> material managed for the verification (CRLContentType,
> OCSPContentType,
> CertificateContentType...)
OK. Now we have 3 levels. See above.
>
> I would say that if we do it, we may satisfy requirements of
> different
> implementers without forcing them to completely develop all the types
> when it might happen that they do not need them.
>
> Another general comment, could we talk of "ValidationData"
> instead of
> "SignedObject" when referring to data that have been used during the
> process of verification of the signature?
I changed it where appropriate. But the generalization of signature and
validation data (i.e. certificate, OCSP-response, time stamp,
etc.) is still called "signed object". I think that this is ok, but we
may discuss this.
>
> Specific comments:
>
> Line 127-128: the writing does not actually say that the basic level
> does not require the incorporation of the <SignedObjectIdentifier> as
> specified in the profile. Suggest to explicitly mention it.
Well, my understanding is that even the Basic level (i.e. verification
of multiple
signatures) REQUIRES the use of SignedObjectIdentifiers as otherwise it
does not seem
to be clear to which signature a specific result corresponds. Did I miss
something?
>
> Line 168: I would say that the document re-defines the DetailType
> semantics. In the core, the Type attribute is allocated for
> identifying
> what object is being reported. In this profile, it is used
> for reporting
> validity, invalidity or incompletness...should we consider to
> define a new
> type within a different namespace?
Yes, now we have the VerificationResultType.
>
> Line 204: <IncludeRevocationValues>. Is it not missing
> similar text to
> <IncludeCertificateValues> "signature (in binary form or as
> equivalent
> XML structure)"?
Yes, thanks for the hint.
>
> Line 208: Suggest to start: "If this element is set to true
> the server's
> response MUST include....."
OK. Considering the redefined conformance levels the
sentence reads:
"<ExpandBinaryValues> [Default]
If this element is set to true a server which fulfills the conformance
level "Convenient" MUST include the content of certificates and
revocation information not only as ASN.1-coded binary values into the
verification report, but also as equivalent XML structures. This option
defaults to 'false'."
>
> Line 220: suggest substitute "For every signature, the
> certificate path
> and each individual certificate the details are reported" by
> "For every
> signature, the certificate path details and details on the
> validation of
> individual certificates in the path are requested".
OK.
>
> Line 220: Start with: "If the element <ReturnVerificationReport> is
> provided as optional input in the request, the server MUST include in
> the response the element <VerificationReport> optional output:"
OK.
>
> Line 234: Answer to comment by Detlef: we decided to move the name to
> the last version of SAML. I am not sure we have implemented this yet.
> Should this need an editorial note? As for my comment, what
> about also
> allowing to identify the verifier by other means different to saml
> identifiers? Could it be possible to define a type with a choice on
> different already known ways? Not strong on this....we may go
> for CD and
> discuss internally....
OK. The current identifier allows to use SAML1.x, SAML2.0, an X.509Data
or something else.
>
> Line 249. Suggest: "For each independent signed object (time stamp,
> certificate, CRL, OCSP-response, evidence record, the
> signature itself,
> etc.) that has been used in the signature(s) verification
> process there
> will be one .....".
OK, but I started the sequence with the signature.
>
> Line 277: SIgnedObjectIdentifierType. Which ones of its children are
> used when the object reported is a signature and which ones
> are used for
> reporting on other type of objects? Is there a rule? Should
> this not be
> mentioned? I think that most of them and the attributes are
> for when the
> reported object is actually a signature...but again, text
> should be added
> to make it clear what elements/attributes are used with what types of
> objects reported.
Yes, I tried to provide some more details and recommendations which
elements SHOULD be
used in which cases.
>
> Line 331: There is no a DetailedReportType defined. Substitute by
> DetailedSignatureReportType
OK.
>
> Line 410: as comment for line 331.
OK.
>
> Line 510: Suggest to use one of the RFC that specifies how to
> represent
> as String a Distinguished Name
OK. Referred to RFC 4514.
>
> Line 505: Suggest starting:" If present, this element indicates...:"
OK.
>
> Line 509 and 512,
No. The elements ValidityPeriodOK and ExtensionsOK are mandatory.
> 518: as above.
OK.
>
> This is a general comment: there are a number of children optional
> elements, whose description starts:
> "This element MAY contain...". Actually it seems that is saying, it
may
> contain this but also may contain other things....I would
> suggest to start
> their description with: "If present this element [contains /
> indicate ] ...."
Yes, I tried to fix this and hope that a captured all relevant
instances.
>
>
> Line 536: Why SignatureAlgorithm in CertificateContentType is of type
> dss:DetailType? Would not be an URI (or a String, as the
> algorithm for
> the certificate is given as an OID) more suitable ?
Yes, changed type to anyURI.
>
> Line 538: Suggest change the <Validity> tag to
> <ValidityPeriod>....we are
> dealing with Validity elements that refer to the status of
> things, and
> this element is just for the period when the certificate may be used.
OK.
>
> Line 558: see my former comment for line 510.
OK.
> Line 540: <Extensions>. The document allows to include extensions but
> does not define any...which I think is OK given the fact that
> there are so
> many extensions...but then, we may end up with different ways
> of reporting
> on certificate extensions.... Is it really necessary to include such
> extensions to the report of the certificate?. Anyway, I think
> that text
> explaining that this element is for reporting on the
> extensions found,
> is missing.
Yes, the text now is:
"<Extensions> [Optional]
If present, this element contains information about the list of
extensions present in the certificate under consideration. The
ExtensionsType is defined below."
Furthermore I changed the text for ExtnValue, which is now OPTIONAL:
"<ExtnValue> [Optional]
This element SHOULD contain the value of the extension as an
XML-structure, which mirrors the original ASN.1-definition of the
extension.
"
> Line 717: CertificatePathValidity for a CRL. First, some text
> should be
> added making it clear that the path is the path for the signing
> certificate of the CRL.
OK. The text now is:
"<CertificatePathValidity> [Required]
This element contains the result of the validation of the certificate
path of the certificate which has been used to sign the CRL. The
CertificatePathValidityType is defined at the beginning of Section
3.5.3."
> Second, I think that this element brings
> recursivity....
> Imagine that we have the following trust framework: RootCA ->
> LevelACA
> -> LevelB CA -> signer.
> We have four certificates: RootCACert, LevelACACert and LevelBCACert.
> We have three CRLs: RootCACRL, LevelACACRL and LevelBCACRL.
>
> The LevelBCACRL has as certPath: LevelBCACert, LevelACACert,
> RootCACert.
> The <CertificatePathValidity> element would include details on these
> three certificates-
>
> The LevelACACRL has as certPath: LevelACert, RootCACert, which are
> present in the former one. What is the point in repeating
> that this path
> is OK if this has been already said?
As explained above I think that the CertificatePathValidity-element
should be
Included in each case, but one MAY omit the details WITHIN the
certificate path.
>
> Line 747: <Signature>. If this element is for indicating the
> algorithm
> of the signature, I would propose to name it differently. This name
> seems a bit misleading.... In addition to that, would not a String be
> enough for an algorithm identifier (OID)?
Yes, changed type to anyURI.
> Line 740: I have the same concerns with the CrlExtensions
> than with the
> certificate extensions.
Yes, changed text as above.
>
> Line 776: same comment as to line 717.
Did you mean line 798 (<CertificatePathValidity>)? In this case I
changed
the text as above.
> Line 815, 865: same concern for OCSP extensions than for CRL
> extensions
> and certificate extensions.
Yes, changed text as above.
>
> Line 861, 863: suggest referring to the OCSP RFC 2560 section 2.4 for
> specifying what comes there.
OK. I provided some details concerning the mapping to the
VerificationResultType.
>
> Line 923: Not sure of making distinctions between
> SignedSignatureProperties and SignedDataObjectProperties. This is a
> rather XAdES oriented classification of properties that CAdES
> does not
> have, for instance....
Well, even if the structure is based on XAdES it seems to be possible to
map the most important CAdES-attributes to this structure. We should
discuss how
we want to handle the remaining (technical and ESS-introduced)
attributes without
direct mapping:
X Signed Attributes
* Attributes defined in CMS
- ContentType -> DataObjectFormat with some explanation
- MessageDigest -> ? (necessary? ... only technical construction)
- SigningTime -> SigningTime
* Attributes defined in ESS
- SigningCertificate -> SigningCertificate
- ContentIdentifier -> ? (necessary? ... only relevant for S/MIME?)
- ContentReference -> ? (necessary? ... only relevant for S/MIME?)
- ContentHints -> DataObjectFormat with some explanation
* Attributes defined in CAdES
- SignaturePolicyIdentifier -> SignaturePolicyIdentifier
- CommitmentTypeIndication -> CommitmentTypeIndication
- SignerLocation -> SignatureProductionPlace
- SignerAttributes -> SignerRole
- ContentTimestamp -> IndividualDataobjetcsTimeStamp
X Unsigned Attributes
* Attribute defined in CMS
- Countersignature -> CounterSignature
* Attribute defined in CAdES
- SignatureTimeStampToken -> SignatureTimeStamp
- CompleteCertificateRefs -> CompleteCertificateRefs
- CompleteRevocationRefs -> CompleteRevocationRefs
- AttributeCertificateRefs -> AttributeCertificateRefs
- AttributeRevocationRefs -> AttributeRevocationRefs
- CertificateValues -> CertificateValues
- RevocationValues -> RevocationValues
- ESCTimeStampToken -> SigAndRefsTimeStamp
- TimestampedCertsCRLs -> RefsOnlyTimeStamp
- ArchiveTimeStampToken -> ArchiveTimeStamp
>
> Line 951 and the following: would not it be better to just use ref
> mechanisms in this piece of XML schema: <element
> ref="xades:SigningCertificate"> and so on, as it seems that
> this element
> will be filled with the corresponding properties of XAdES or
> attributes
OK. Changed XSD to use refs to XAdES-elements.
> from CAdES?...and by the way, have we checked that the CAdES
> attributes
> map so immediately in XAdES properties?... I would say that
> transposition of most of them is not difficult, but maybe we
> should make
> a careful double check...
See above. We should discuss how we should treat the few technical/ESS
attributes,
which do not have a mapping.
>
> Line 1016, 1056: same as before.
OK.
>
> Line 1314: same concerns for attr cert extensions as for
> other extensions.
OK. Changed text as above.
>
> Line 1225: See my comment on whether the
> <certificatePathValidity> has
> to be mandatory or not applied to other validation data objects.
IMHO it should be mandatory, but the details WITHIN the path may be
omitted,
if they are already present in the verification report.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
oups.php
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]