> 27 mar 2015 kl. 18:43 skrev Massimiliano Pala <[email protected]>: > > Hi Rob, all, > > last consideration about the I-D - there are a bunch of OID values that are > used throughout the document that are using PRIVATE (Google) OIDs in the > document - this is completely wrong! Private OIDs should not be used for I-Ds. > sais who? > The authors should request a new OID assigned for trans under (most probably) > the id-pkix OID and then define the required OIDs in that space. This should > also be reflected, I think, in the IANA consideration section. > > For example: > > id-trans OBJECT IDENTIFIER ::= { id-pkix XX } > id-trans-xxxx OBJECT IDENTIFIER ::= { id-trans 1 } > ... > > Cheers, > Max > > P.S.: Cross posting this message to the TRANS ml so that the WG can consider > these issues in the I-D. > > >> On 3/27/15 12:44 PM, Massimiliano Pala wrote: >> Hi Rob, all, >> >> coming to your question: the extension will not break compatibility as long >> as it is not marked critical. However, there might be some aspects you want >> to think a bit more deeply about before taking a decision. >> >> This said, I think that the text written in section 3.4.2 is wrong and needs >> to be replaced. >> >> In particular, the argument about the encoding is weird - from the I-D: >> One or more SCTs can be embedded in an X.509v3 extension that is >> included in a certificate or an OCSP response. Since RFC5280 >> requires the "extnValue" field (an OCTET STRING) of each X.509v3 >> extension to include the DER encoding of an ASN.1 value, we cannot >> embed a "SignedCertificateTimestampList" directly. Instead, we have >> to wrap it inside an additional OCTET STRING (see below), which we >> then put into the "extnValue" field. >> In my opinion, this text should be removed (trying to justify the use of a >> data type in the encoding because you do not want to define the required >> structure in ASN.1 does not really look.. good in an I-D, I am surprised it >> is even there). >> >> However, more considerations are required here. If you want the extension to >> have a non-ASN.1 structure it is fine, but that will have implication over >> the (format) compliance of data in the certificate. This was marginally >> mentioned in previous posts, but it seems it requires a more explicit >> explanation since it was not well understood. >> >> In particular, from a parsing perspective, when using the proposed encoding, >> the client will not perform any validation over the contents of the >> extension since this is just a blob. Usually this type of encoding is used >> for binary contents that have no internal structure (e.g., a value of a key >> or a digest), but it is usually avoided for complex types (again, to provide >> format validation of the contents). >> >> The real question here is: are you willing to live with not validating the >> format of the content of the extension when the extension is actually >> parsed? Are you considering the possible attack vectors that can derive from >> that (i.e. allowing custom contents in the extension)? I hope you already >> discussed these aspects before proposing the extension. If not, my >> suggestion is to go back to the drawing board and seriously considering >> these aspects. If you go ahead with the current choice, I would suggest to >> remove the 3.4.2 text and add some considerations about it in the security >> considerations section (although, in that case I would STRONGLY suggest to >> revisit your choice). >> >> This is usually a good rule of thumb when it comes to adding extensions. >> >> Another operational consideration that was pointed out is about debugging >> the bits on the wire. If you use ASN.1 structures, standard network tools >> can parse the extension properly - however, again, this will not be the case >> for OCTET STRING blobs. Thus, debugging of the extension (in case of issues) >> can only happen at the end points (where the extension parser is available), >> not on the wire. >> >> I hope this helps clarifying the issues with the current proposal. >> >> Just my 2 cents. >> >> Cheers, >> Max >> >> >>> On 3/25/15 9:44 AM, Rob Stradling wrote: >>>> On 25/03/15 14:20, Sean Leonard wrote: >>>> On Mar 18, 2015, at 2:10 AM, Peter Gutmann <[email protected]> >>>> wrote: >>>> >>>>> Melinda Shore <[email protected]> writes: >>>>> >>>>>> it's what's in the document until someone can either point to some >>>>>> normative >>>>>> specification that it violates or can point to something that actually >>>>>> would >>>>>> break. >>>>> >>>>> This isn't a case of standards rules-lawyering though (in any case the >>>>> PKIX >>>>> spec is flexible enough that you can stuff anything you want into a >>>>> certificate if you interpret things just right, see the famous >>>>> MPEG-of-cat >>>>> quote), it's that this is creating a situation where an *X.509 standards- >>>>> compliant certificate* contains data that can't be processed by an *X.509 >>>>> standards-compliant certificate application*. >>>> >>>> I agree with Peter. Keep the encoding as ASN.1 for this extension. It is >>>> not particularly onerous, and it preserves compatibility for other >>>> applications. >>> >>> How exactly might the certificate extension we're talking about [1] break >>> compatibility with other applications? >>> >>> The Subject Key Identifier extension uses the exact same ASN.1 syntax (the >>> content of the extension is a plain OCTET STRING). RFC5280 does not >>> require applications to recognize this extension. >>> >>> I'm not aware of any applications that choke on the Subject Key Identifier >>> extension, so why should we expect any to choke on the 6962-bis extension? >>> >>> >>> [1] >>> https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/?include_text=1 >>> Sections 3.4.2 and 3.4.2.2 >> >> >> >> _______________________________________________ >> pkix mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/pkix > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
