On 04-Sep-20 05:00, Toerless Eckert wrote:
> inline..
>
> a) Wrt. X.520: From ITU's page:
>
> | This text was produced through a joint activity with ISO and IEC.
> | According to the agreement with our partners, this document is only
> available through payment.
>
> Of course, ITU shouldn't enter into such partnership, but given how common
> public-private partnerships are in western governments, its hardly unusual.
The IETF has many, many normative references to ITU recommendations despite
their
paywall, and has done for 30 years or so.
> Given how all certificate work in IETF is based off X.500 certificates, it
> would be
> a great job for the IETF/ITU-T liaison to see how IETF work could get free
> access
> to the according ITU-T documents.
I don't think we should worry about it at WG level. There's no standards process
problem in citing ITU-T documents.
Brian
>
> b) I am confused about your text up to the diff -24 to -43. Is there an
> executive
> summary how this relates to the issue i brought up ?
>
> c) Of course, you are welcome trying to avoid X.520 and instead step into
> X520SerialNumber,
> so your diff is fine to me.
>
> [ The fixes i am proposing to Ben re serialNumber in ACP
> will attempt to avoid X520SerialNumber because i don't even understand
> how this
> explicit tagging works and no CLI/document has ever used these terms
> (except for the ASN.1 rfcs about them].
>
> d) I am mostly wondering if/how changes like this would go into the final
> BRSKI RFC
> given its state in RFC editor queue. I don't understand what type of text
> fixes will be accepted as just editorial, not requiring the whole shebang
> of
> IETF process steps we're just doing for the other BRSKI fix....
>
> Cheers
> Toerless
>
>> I seem to remember requests for clarification many months, and I wonder if it
>> was part of a different piece.
>> https://mailarchive.ietf.org/arch/msg/anima/mBNQoRCTECyQ0G-D9AnEWgLaHUc/
>> https://mailarchive.ietf.org/arch/msg/anima/vpItLADnu-2Ea-uB0A9fHjia4hw
>>
>> confusingly, we discussed rfc5280 4.2.1.2 a bunch, but not 4.1.2.2.
>> It looks like as a result of the thread starting at:
>> ** https://mailarchive.ietf.org/arch/msg/anima/oR0POVwZ24EZEVD3S4XCXdNmtSE/
>> and specifically
>> https://mailarchive.ietf.org/arch/msg/anima/8Ys6ctjFeyINat_BGg860b04I3E/
>> That made me rewrite that section, and it appears that I did too quick a
>> search of RFC5280.
>>
>> It's a tribute to this Internet thing we built that the tinyurl.com in the **
>> noted email leads to:
>>
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-24&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/master/dtbootstrap-anima-keyinfra.txt
>>
>> Which works great, and show you the text that got replaced.
>> However, the above link will likely give you a different result as I'm about
>> to push the fix to the fix.
>>
>> Try, instead:
>>
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-24&url2=draft-ietf-anima-bootstrapping-keyinfra-43
>
>
>> Toerless Eckert <[email protected]> wrote:
>> > BRSKI section 2.3.1:
>>
>> > | The serialNumber field is defined in [RFC5280]. That specification
>> > | allows for the field to be omitted if there is a good technical
>> > | reason. IDevID certificates for use with this protocol are REQUIRED
>> > | to include the "serialNumber" attribute with the device's unique
>> > | serial number (from [IDevID] section 7.2.8, and [RFC5280] section
>> > | 4.1.2.2's list of standard attributes).
>>
>> > The serialNumber field defined in [RFC5280] 4.1.2.2 is not the subject
>> > DN serialNumber (a string) that we want to talk about, but the
>> certificate serial
>> > number (a number). That serialNumber string is actually defined in
>> [X.520],
>> > for which BRSKI does unfortunately not have a reference. See for
>> example
>> > [RFC4519] used in BRSKI as an example for a serialNumber, it point
>> correctly
>> > to [X.520].
>>
>> X.520 is behind an impossible to use paywall. From what I can tell, it's
>> actually run on a for-profit basis within each national boundary, and the one
>> within my national boundary is incompetent.
>> I am of the opinion that the ITU is violating the UN convention on human
>> rights when they do this.
>> So, to me, any X520 reference will result in less understanding rather than
>> more.
>
> On Tue, Sep 01, 2020 at 09:43:49PM -0400, Michael Richardson wrote:
>>
>> I find the text in 2.3.1 paragraph two of BRSKI, which you quote to be
>> startlingly wrong.
>> As you say, that's not the id-at-serialNumber we were looking for, and the
>> one we want is defined in RFC5280 as X520SerialNumber.
>>
>> The example of RFC4519, section 2.31 is a correct reference.
>>
>> > Aka: I am not sure exactly what the minimum editorial fix is:
>>
>> > "The serialNumber field is defined in [RFC5280]"
>>
>> > This is AFAIK not correct unless A.1 definition of X520SerialNumber can
>> > be represented as definition of serialNumber. More easily,
>> serialNumber is
>> > defined in [X.520]
>>
>> > "and [RFC5280] section 4.1.2.2's list of standard attributes"
>>
>> > this is wrong.
>>
>> > "and [RFC5280] section A.1's list of standard attributes"
>>
>> https://github.com/anima-wg/anima-bootstrap/commit/c7a7eb46e78d761c5cb0f50a9dfa95f820d74b99
>>
>> commit c7a7eb46e78d761c5cb0f50a9dfa95f820d74b99
>> Author: Michael Richardson <[email protected]>
>> Date: Tue Sep 1 21:25:05 2020 -0400
>>
>> fix section 2.3.1 to point at X520SerialNumber
>>
>> diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
>> index d655d69..9739945 100644
>> --- a/dtbootstrap-anima-keyinfra.xml
>> +++ b/dtbootstrap-anima-keyinfra.xml
>> @@ -799,18 +799,24 @@ INSERT_TEXT_FROM_FILE component-diagram.txt END
>> </t>
>>
>> <t>
>> - The serialNumber field is defined in <xref target="RFC5280" />.
>> - That specification allows for the field to be omitted if there
>> is
>> - a good technical reason. IDevID certificates for use
>> - with this protocol are REQUIRED to include the "serialNumber"
>> attribute with the device's
>> - unique serial number
>> - (from <xref target="IDevID" /> section 7.2.8, and
>> - <xref target="RFC5280" /> section 4.1.2.2's list of standard
>> - attributes).
>> - </t>
>> - <t>
>> - The serialNumber field is used as follows by the pledge to
>> build the
>> - "serial-number" that is placed in the voucher-request.
>> + There is a (certificate) serialNumber field is defined in <xref
>> + target="RFC5280" /> section 4.1.2.2. In the ASN.1, this is
>> + referred to as the CertificateSerialNumber. This field is NOT
>> + relevant to this specification. Do not confuse this field with
>> + the "serial-number" defined by this document, or by
>> + <xref target="IDevID" /> and <xref target="RFC4519" /> section
>> + 2.31.
>> + </t>
>> +
>> + <t>
>> + The device serial number is defined in <xref target="RFC5280" />
>> + section A.1 and A.2 as the X520SerialNumber, with the OID tag
>> + id-at-serialNumber.
>> + </t>
>> + <t>
>> + The device serial number field (X520SerialNumber) is used as
>> + follows by the pledge to build the "serial-number" that is
>> placed
>> + in the voucher-request.
>> In order to build it, the fields need to be converted into a
>> serial-number of "type string".
>> </t>
>> @@ -821,8 +827,7 @@ INSERT_TEXT_FROM_FILE component-diagram.txt END
>> </t>
>> <t>
>> Due to the reality of existing device identity provisioning
>> - processes, some
>> - manufacturers have stored serial-numbers in other
>> + processes, some manufacturers have stored serial-numbers in
>> other
>> fields. Registrar's SHOULD be configurable, on a
>> per-manufacturer
>> basis, to look for serial-number equivalents in other fields.
>> </t>
>>
>> --
>> Michael Richardson <[email protected]>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>
>
>
>> _______________________________________________
>> Anima mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/anima
>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
