Skip to content

Commit

Permalink
md: aside consistency (#34)
Browse files Browse the repository at this point in the history
* md: aside consistency

Making the aside blocks consistent

* xml2rfc doesn't like aside in abstract
  • Loading branch information
seanturner authored Oct 23, 2023
1 parent 0d214c8 commit 0eb309f
Showing 1 changed file with 23 additions and 23 deletions.
46 changes: 23 additions & 23 deletions draft-ietf-lamps-kyber-certificates.md
Original file line number Diff line number Diff line change
Expand Up @@ -79,11 +79,11 @@ algorithm identifiers and ASN.1 encoding format for Kyber in public
key certificates. The encoding for public and private keys are also
provided.

\[EDNOTE:
\ [EDNOTE:
This document is not expected to be finalized before the NIST PQC
Project has standardized PQ algorithms. This specification will use
object identifiers for the new algorithms that are assigned by NIST,
and will use placeholders until these are released.]
and will use placeholders until these are released.

--- middle

Expand Down Expand Up @@ -136,8 +136,8 @@ is defined as follows:
~~~

<aside markdown="block">
NOTE: The above syntax is from {{!RFC5912}} and is compatible with the
2021 ASN.1 syntax {{X680}}.
: The above syntax is from {{!RFC5912}} and is compatible with the
2021 ASN.1 syntax {{X680}}.
</aside>

The fields in AlgorithmIdentifier have the following meanings:
Expand All @@ -152,12 +152,12 @@ The fields in AlgorithmIdentifier have the following meanings:
Kyber-1024. For all of these OIDs, the parameters MUST be absent.

<aside markdown="block">
NOTE: It is possible to find systems that require the parameters to be
present. This can be due to either a defect in the original 1997
syntax or a programming error where developers never got input where
this was not true. The optimal solution is to fix these systems;
where this is not possible, the problem needs to be restricted to
that subsystem and not propagated to the Internet.
: It is possible to find systems that require the parameters to be
present. This can be due to either a defect in the original 1997
syntax or a programming error where developers never got input where
this was not true. The optimal solution is to fix these systems;
where this is not possible, the problem needs to be restricted to
that subsystem and not propagated to the Internet.
</aside>


Expand Down Expand Up @@ -205,9 +205,9 @@ certificate extension MUST only contain keyEncipherment


<aside markdown="block">
NOTE: As noted in Section 3, the values for these object identifers
will be assigned by NIST. Once assigned, they will be added to a future
revision of this document.
: As noted in Section 3, the values for these object identifers
will be assigned by NIST. Once assigned, they will be added to a future
revision of this document.
</aside>


Expand All @@ -224,8 +224,8 @@ SubjectPublicKeyInfo type, which has the following ASN.1 syntax:
~~~

<aside markdown="block">
NOTE: The above syntax is from {{RFC5912}} and is compatible with the
2021 ASN.1 syntax {{X680}}.
: The above syntax is from {{RFC5912}} and is compatible with the
2021 ASN.1 syntax {{X680}}.
</aside>

The fields in SubjectPublicKeyInfo have the following meaning:
Expand Down Expand Up @@ -283,8 +283,8 @@ algorithm itself.
~~~

<aside markdown="block">
NOTE: The above syntax is from {{RFC5958}} and is compatible with the
2021 ASN.1 syntax {{X680}}.
: The above syntax is from {{RFC5958}} and is compatible with the
2021 ASN.1 syntax {{X680}}.
</aside>

For the keys defined in this document, the private key is always an
Expand Down Expand Up @@ -318,12 +318,12 @@ prior example, the textual encoding defined in {{RFC7468}} is used:
~~~

<aside markdown="block">
NOTE: There exist some private key import functions that have not
implemented the new ASN.1 structure OneAsymmetricKey that is defined in
{{RFC5958}}. This means that they will not accept a private key
structure that contains the public key field. This means a balancing
act needs to be done between being able to do a consistency check on the
key pair and widest ability to import the key.
: There exist some private key import functions that have not
implemented the new ASN.1 structure OneAsymmetricKey that is defined in
{{RFC5958}}. This means that they will not accept a private key
structure that contains the public key field. This means a balancing
act needs to be done between being able to do a consistency check on the
key pair and widest ability to import the key.
</aside>

# ASN.1 Module
Expand Down

0 comments on commit 0eb309f

Please sign in to comment.